Skip to content
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

binder: plan not optimal for count(*) with filter #559

Merged
merged 3 commits into from
Mar 16, 2022

Conversation

xiaoyong-z
Copy link
Contributor

Signed-off-by: xiaoyong-z a997647204@gmail.com

close #482

For select statement, set with_row_handler to be true when "with_row_handler = true" and "column_ids.is_empty()".
For delete statement, always set with_row_handler to be true.

Signed-off-by: xiaoyong-z <a997647204@gmail.com>
@skyzh skyzh requested review from xxchan and skyzh March 10, 2022 15:31
Copy link
Member

@xxchan xxchan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you show some example plans?

@@ -140,7 +141,7 @@ impl LogicalPlaner {
*ref_id,
column_ids.to_vec(),
column_descs.to_vec(),
with_row_handler,
is_delete || (with_row_handler && column_ids.is_empty()),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is it && instead of ||?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And is the with_row_handler parameter still needed? Can we derive it directly here?

BTW, I think it is not enough to only handle it here in planner. Maybe in optimizer instead, as mentioned in #503.

Copy link
Contributor Author

@xiaoyong-z xiaoyong-z Mar 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, the "is_delete" flag indicates whether the plan is from a delete statement.
For "delete" statement, always set with_row_handler to be true as "is delete" flag is true for "delete" statement.
For "select" statement, the "is_delete" flag is false, and then we need to further check if the with_row_handler is true and column_ids is empty. Here i use the && insteand of || is to ensure that when we already have some column scans, we don't need the row_handler, the picture following points out this problem.

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think for "delete" statement, it is not needed. For "select" statement, may be it is still needed?

And is the with_row_handler parameter still needed? Can we derive it directly here?

For this bug in the #482, I think handle it in the planner is enough? In #503, i didn't see how to handle this part in optimizer, can you give me more insights?

BTW, I think it is not enough to only handle it here in planner. Maybe in optimizer instead, as mentioned in #503.

Copy link
Member

@xxchan xxchan Mar 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering why planner still needs to compute with_row_handler when it is a given parameter? Does it mean that the argument is wrong?
It may look better if it is either completely computed here or simply passed as argument.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now the computation of with_row_handler is only in plan_select function.

Signed-off-by: xiaoyong-z <a997647204@gmail.com>
@skyzh skyzh enabled auto-merge (squash) March 16, 2022 13:08
@skyzh skyzh merged commit f60f2ad into risinglightdb:main Mar 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

binder: plan not optimal for count(*) with filter
3 participants