perf: direct linear scan for implicit-whole-table-group aggregates (#633) - #637
Merged
Conversation
) compile_grouped_scan unconditionally opened a Sorter even for aggregates with no GROUP BY key at all (#287's implicit whole-table group), paying a MakeRecord/SorterInsert/SorterSort/SorterData round trip per WHERE-matching row for nothing to sort by. Adds try_compile_direct_agg_scan: a new fast-path tier between the existing try_compile_index_only_count/sum narrow cases and the compile_grouped_scan fallback. Fires whenever no aggregate call uses DISTINCT, doing a single Rewind/Next scan with AggStep folded in inline, reusing flush_group/AggSlot/ compile_limit_setup so HAVING, LIMIT/OFFSET, and #287's zero-row-still- flushes-one-row behavior are unchanged. spend: matched estimate (medium)
iheitlager
force-pushed
the
perf/633-direct-agg-scan
branch
from
August 29, 2026 08:50
754a5ef to
c61b263
Compare
No version bump — staying on 0.18.7 per the just-combined 0.18.7/0.18.8 release (#638).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
compile_grouped_scanunconditionally opened aSortereven for aggregates with noGROUP BYkey at all (feat: support aggregates with no GROUP BY (implicit whole-table group) #287's implicit whole-table group) — everyWHERE-matching row paid aMakeRecord/SorterInsert/SorterSort/SorterDataround trip for nothing to sort by.try_compile_direct_agg_scan(src/codegen/select/aggregate.rs): a new fast-path tier between the existingtry_compile_index_only_count/try_compile_index_only_sumnarrow cases and thecompile_grouped_scanfallback, wired into dispatch insrc/codegen/select/entry.rs.DISTINCT(the only case it declines): a singleRewind/Nextscan folds matching rows viaAggStepinline, noSorteropcode at all. Reusesflush_group/AggSlot/compile_limit_setupdirectly, soHAVING,LIMIT/OFFSET, and feat: support aggregates with no GROUP BY (implicit whole-table group) #287's "zero-row table still flushes one row" behavior are unchanged.Verified via
EXPLAINon theagg_subquerybenchmark query that the outercount(*)scan now compiles with zeroSorteropcodes (the remainingSorterOpen/SorterInsert/SorterSortbelongs to the inner, separately-compiledavg(x)subquery — out of scope here).Test plan
cargo test --test codegen_select(40/40, includingaggregate_without_group_by_implicit_whole_table_groupandhaving_without_group_by_filters_the_implicit_group)make test(full suite, 0 failures)make lint(clippy + fmt clean)EXPLAINinspection confirms noSorteropcode on the direct-agg-scan pathcargo bench --bench engine -- agg_subquery --quick): 50MB fixture ~255ms (down from the issue's reported ~275ms baseline; oracle ~15ms) — modest improvement since the outercount(*)was only part of the gap; the inneravg(x)subquery's ownSorter(unindexed column, separate compile path) is now the dominant remaining cost, tracked separatelyspend: matched estimate (medium)
Closes #633