Uh oh!
There was an error while loading. Please reload this page.
Row group limit pruning for row groups that entirely match predicates - #18868
Conversation
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
52f012f to
d075c86CompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
xudong963
commented
Nov 25, 2025
I also like to construct some good-fit cases to show some benchmark results. |
aaf76c0 to
cb5711dComparealamb
commented
Nov 25, 2025
I plan to review this PR carefully tomorrow |
alamb
left a comment
There was a problem hiding this comment.
Thank you very much for this PR @xudong963
The idea is very cool, and a nicely done PR; I have several suggestions, but I think it is very close.
Suggestions:
- Rename the flag to
preserve_order - Make this new flag on TableScan visible in EXPLAIN plans so we have a better chance of understanding when it is being applied/not applied
- Implement an end to end test for the behavior you want to see (specifically, a test that shows a query on a parquet file and demonstrates that only a single row group is fetched with this flag, and more than one is fetched without the flag)
In my mind, 3 is the most important
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
alamb
commented
Nov 27, 2025
🤖 |
alamb
commented
Nov 27, 2025
🤖: Benchmark completed Details |
fdef903 to
7e1fc4fCompare90295f9 to
63cd878Comparexudong963
commented
Nov 28, 2025
Thanks for the review @alamb . I addressed some suggestions:
Things later the PR:
|
alamb
commented
Dec 1, 2025
I was mentioning this PR to @crepererum and he also noted there is another interesting potential optimization when we know the predicate is true for the entire row group: we can skip evaluating the predicate for the row group entirely (as the filter can often be quite expensive itself) @xudong963 is this something else you are contemplating? This PR likely lays the foundation for such an optimization. If you think it is worthwhile I'll file a ticket |
alamb
commented
Dec 1, 2025
I just reviewed this -- it looks nice 👍 |
2e82b97 to
ca7de4fCompare70375e5 to
6c515b2Comparexudong963
commented
Jan 16, 2026
adriangb
commented
Jan 16, 2026
Should we also have an issue to track using this idea / machinery to avoid running filters that we know match all rows for a file during filter pushdown? |
xudong963
commented
Jan 16, 2026
Yes, this one #19028 |
alamb
commented
Jan 16, 2026
This is super exciting work -- thank you so much @xudong963 and @adriangb Interestingly I was just speaking about this feature with @NGA-TRAN and @gene-bordegaray (who I ran into at https://nedbday.github.io/2026/). Very cool |
run benchmarks |
alamb-ghbot
commented
Jan 16, 2026
🤖 |
alamb-ghbot
commented
Jan 16, 2026
🤖: Benchmark completed Details |
run benchmarks |
alamb-ghbot
commented
Jan 16, 2026
🤖 |
alamb-ghbot
commented
Jan 16, 2026
🤖: Benchmark completed Details |
NGA-TRAN
commented
Jan 18, 2026
Thanks @alamb for letting us know this great feature. |
…apache#18868) <!-- We generally require a GitHub issue to be filed for all bug fixes and enhancements and this helps us generate change logs for our releases. You can link an issue to this PR using the GitHub syntax. For example `Closesapache#123` indicates that this PR will close issue apache#123. --> - Part of apache#18860 <!-- Why are you proposing this change? If this is already explained clearly in the issue then this section is not needed. Explaining clearly why changes are proposed helps reviewers understand your changes and offer better suggestions for fixes. --> See apache#18860 (comment) <!-- There is no need to duplicate the description in the issue here but it is sometimes worth providing a summary of the individual changes in this PR. --> 1. How to decide if we can do limit pruning without messing up the sql semantics. 2. Add logic to decide if a row group is fully matched, all rows in the row group are matched the predicated. 3. Use the fully matched row groups to return limit rows. <!-- We typically require tests for all PRs in order to: 1. Prevent the code from being accidentally broken by subsequent changes 3. Serve as another way to document the expected behavior of the code If tests are not included in your PR, please explain why (for example, are they covered by existing tests)? --> Yes <!-- If there are user-facing changes then we may require documentation to be updated before approving the PR. --> <!-- If there are any breaking changes to public APIs, please add the `api change` label. --> No, no new configs, or API change
…apache#18868) <!-- We generally require a GitHub issue to be filed for all bug fixes and enhancements and this helps us generate change logs for our releases. You can link an issue to this PR using the GitHub syntax. For example `Closesapache#123` indicates that this PR will close issue apache#123. --> - Part of apache#18860 <!-- Why are you proposing this change? If this is already explained clearly in the issue then this section is not needed. Explaining clearly why changes are proposed helps reviewers understand your changes and offer better suggestions for fixes. --> See apache#18860 (comment) <!-- There is no need to duplicate the description in the issue here but it is sometimes worth providing a summary of the individual changes in this PR. --> 1. How to decide if we can do limit pruning without messing up the sql semantics. 2. Add logic to decide if a row group is fully matched, all rows in the row group are matched the predicated. 3. Use the fully matched row groups to return limit rows. <!-- We typically require tests for all PRs in order to: 1. Prevent the code from being accidentally broken by subsequent changes 3. Serve as another way to document the expected behavior of the code If tests are not included in your PR, please explain why (for example, are they covered by existing tests)? --> Yes <!-- If there are user-facing changes then we may require documentation to be updated before approving the PR. --> <!-- If there are any breaking changes to public APIs, please add the `api change` label. --> No, no new configs, or API change
…apache#18868) ## Which issue does this PR close? <!-- We generally require a GitHub issue to be filed for all bug fixes and enhancements and this helps us generate change logs for our releases. You can link an issue to this PR using the GitHub syntax. For example `Closesapache#123` indicates that this PR will close issue apache#123. --> - Part of apache#18860 ## Rationale for this change <!-- Why are you proposing this change? If this is already explained clearly in the issue then this section is not needed. Explaining clearly why changes are proposed helps reviewers understand your changes and offer better suggestions for fixes. --> See apache#18860 (comment) ## What changes are included in this PR? <!-- There is no need to duplicate the description in the issue here but it is sometimes worth providing a summary of the individual changes in this PR. --> 1. How to decide if we can do limit pruning without messing up the sql semantics. 2. Add logic to decide if a row group is fully matched, all rows in the row group are matched the predicated. 3. Use the fully matched row groups to return limit rows. ## Are these changes tested? <!-- We typically require tests for all PRs in order to: 1. Prevent the code from being accidentally broken by subsequent changes 3. Serve as another way to document the expected behavior of the code If tests are not included in your PR, please explain why (for example, are they covered by existing tests)? --> Yes ## Are there any user-facing changes? <!-- If there are user-facing changes then we may require documentation to be updated before approving the PR. --> <!-- If there are any breaking changes to public APIs, please add the `api change` label. --> No, no new configs, or API change
Which issue does this PR close?
Rationale for this change
See #18860 (comment)
What changes are included in this PR?
Are these changes tested?
Yes
Are there any user-facing changes?
No, no new configs, or API change