[fix](count) fix wrong count push down logic#56182
Conversation
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
|
run buildall |
TPC-H: Total hot run time: 1498 ms |
TPC-DS: Total hot run time: 2763 ms |
ClickBench: Total hot run time: 0.03 s |
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
|
run buildall |
FE Regression Coverage ReportIncrement line coverage |
TPC-H: Total hot run time: 1489 ms |
TPC-DS: Total hot run time: 2764 ms |
ClickBench: Total hot run time: 0.05 s |
FE UT Coverage ReportIncrement line coverage |
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
FE Regression Coverage ReportIncrement line coverage |
|
run buildall |
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
FE Regression Coverage ReportIncrement line coverage |
793faa2 to
2e290c0
Compare
|
run buildall |
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
FE UT Coverage ReportIncrement line coverage |
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
TPC-H: Total hot run time: 1483 ms |
TPC-DS: Total hot run time: 2745 ms |
ClickBench: Total hot run time: 0.04 s |
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
FE Regression Coverage ReportIncrement line coverage |
|
PR approved by at least one committer and no changes requested. |
|
PR approved by anyone and no changes requested. |
### What problem does this PR solve? Introduced from topn optimization. When executing query like `select count(*) from tbl`, it will trigger "count push down optimization". which means it will send some "dummy" split to BE, each with a part of row count number. But due to the bug, BE will use the range offset info in these dummy split to do the row group filter logic, which is incorrect and will result in empty result because all row group will be filtered. This PR fix it, to not filter the row group if it is a dummy split. How to reproduce: 1. find an iceberg table with file size at least 16MB 2. set file_split_size=4MB 3. select count(*) from table, it will return empty result
Introduced from topn optimization. When executing query like `select count(*) from tbl`, it will trigger "count push down optimization". which means it will send some "dummy" split to BE, each with a part of row count number. But due to the bug, BE will use the range offset info in these dummy split to do the row group filter logic, which is incorrect and will result in empty result because all row group will be filtered. This PR fix it, to not filter the row group if it is a dummy split. How to reproduce: 1. find an iceberg table with file size at least 16MB 2. set file_split_size=4MB 3. select count(*) from table, it will return empty result
The previous guard kept one order key for any non-ranking window whose order keys were all pruned, to avoid leaving a framed window without an ORDER BY. But the guard only ever fires when retainExpression is empty, which means every order key was redundant, i.e. constant within each partition (duplicate / equal to a partition key / uniform / functionally constant). The retained key is therefore always constant and carries no intra-partition ordering, so keeping it only adds a useless sort key and diverges from the existing behavior (eliminateWindow shipped in apache#56182, which already prunes such keys to empty). It also broke the recorded plan in add_project_for_unique_function (window_2): a constant order key over a single-row relation was wrongly retained. Drop the guard. Emptying these keys changes neither the framed result (for a RANGE frame a constant key keeps the whole partition as one peer group, exactly like an empty ORDER BY) nor the partition topn pushdown, and it restores the master baseline. Verified by execution: the query plans, runs, returns correct results, and BE does not crash.
What problem does this PR solve?
Introduced from topn optimization.
When executing query like
select count(*) from tbl, it will trigger "count push down optimization".which means it will send some "dummy" split to BE, each with a part of row count number.
But due to the bug, BE will use the range offset info in these dummy split to do the row group filter logic,
which is incorrect and will result in empty result because all row group will be filtered.
This PR fix it, to not filter the row group if it is a dummy split.
How to reproduce:
Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)