-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug Report: Query planner breaks join with derived table containing a subquery with IN
/NOT IN
#17867
Comments
hii , would like to work on this issue , kinfly assign |
Hello @kairveeehh, thanks for your interest in working on this issue! After internal discussions, we believe this might be a bit complex to tackle without more experience with Vitess. However, if you’re confident that you understand the fix and would like to take it on, you’re more than welcome to give it a try. We typically don’t assign issues to individuals, but feel free to open a PR once you have a solution. Just ensure it’s well-tested and includes the necessary unit and end-to-end tests! |
Joining @GuptaManan100's sentiment that this particular task is not a good fit for a first contribution. Also, we want to see whether @arthurschreiber has intentions of working on that himself. @arthurschreiber ? |
Sure , would understand it further and inform , also I look forward to contribute to the idea of vitess under GSoC'25 the chatbot based over RAG , had texted over slack but received no response , should I directly go to proposal? |
Overview of the Issue
We have run into a query that gets incorrectly broken up by the Query Planner instead of fully being pushed down to MySQL.
Here's a simplified version of that query (using the vschema located at
go/vt/vtgate/planbuilder/testdata/vschemas/schema.json
):The derived table
m2
has enough information to be routed to a specific shard (user_extra
andmusic
have conditions onuser_id
, which is ahash
vindex). The join betweenm1
andm2
happens on a shared lookup vindex.The above mentioned conditions should be enough to have the query fully merged by the query planner and pushed down completely to MySQL. Instead, the query is broken up. Here's the query plan (taken on
main
):Variations of this query get merged correctly. For example, a derived table with a nested join:
The query for the derived table gets merged correctly:
And a join with a derived table without a subquery works fine too:
Reproduction Steps
N/A
Binary Version
Operating System and Environment details
Log Fragments
No response
The text was updated successfully, but these errors were encountered: