-
Notifications
You must be signed in to change notification settings - Fork 1.7k
fix: aggregation corner case #15457
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
fix: aggregation corner case #15457
Conversation
|
Looks correct |
|
but why don't we have "value" column in logical plan schema I thought value should be pushed down to |
it's also an alternative solution. we can keep the column in logical plan. but i think that count(*) actually doesnt depend on any column on input logically. i cannot say current logicalplan is wrong. so i dont know which way is better. |
count(*) need to know the row number of the column, and it doesn't make sense to count all on "empty" column, so I guess keeping the column in logical plan makes more sense |
but, for with test AS (SELECT i as needle FROM generate_series(1, 10) t(i))
select count(*), i from test WHERE 1 = 1 group by i;there's no row number in both physical and logical plan. do you think we should also add row number for this sql? |
In this case, the row number is 1. there are 10 group, each group contains single number. |
|
I found that in the following sql. for the outer aggregation, |
Update generate_series.rs
|
@jayzhan211 could you please review it again? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @chenkovsky
| ) -> Result<Arc<dyn ExecutionPlan>> { | ||
| let batch_size = state.config_options().execution.batch_size; | ||
|
|
||
| let schema = match projection { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great that you find the root cause instead of having a workaround config!
* fix: aggregation corner case * Update generate_series.rs * Update physical_planner.rs * format * Update generate_series.rs
Which issue does this PR close?
panicwhen evaluating trivial WHERE with a CTE #15386 .Rationale for this change
for sql
The root cause is that after
optimize_projections.columns are dropped from logical plan, but in physical plan, there is still a value column.
What changes are included in this PR?
add project in generated series
Are these changes tested?
UT
Are there any user-facing changes?
No