-
Notifications
You must be signed in to change notification settings - Fork 1.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
feat: implement exists subquery #1649
Conversation
55d9fea
to
4b2151e
Compare
956d7f1
to
7d6abae
Compare
b11f2bd
to
409ef3d
Compare
9505474
to
8598c20
Compare
This ticket is actively developing during my chunks of free time, such as weekends and holidays. When I think it's ok, I'll make it ready for review. |
Hi @xudong963, how's the progress? In our case, we need to use in subquery. Do you have plan for that? If no, I'll try to implement that. |
The PR now has finished skeleton, I'll fix the bug and add more tests in the PR on weekend. After the PR is finished, the IN subquery can be easy to add by using the subquery skeleton. |
8598c20
to
bf1fd5a
Compare
Hi, @xudong963 If you do not mind, I can continue working on this PR. |
Thanks @mingmwang, I don't mind at all. I recently changed my job and didn't have much time to move forward. |
Which issue does this PR close?
Closes #1209
But in this ticket, I only implement the exists subquery. I believe this ticket is building a subquery skeleton which will make adding other subqueries convenient.
What changes are included in this PR?
After generating LogicalPlan, if the logical plan contains subqueries, it'll be rewrite to unnesting in logical level. The core advantage is that subqueries won't influence physical level.
Are there any user-facing changes?
Yes, API changes have already taken place in draft implementation.
But users can use subquery!