Skip to content

branch-4.1:[enhance](eager-agg) adjust aggregation push down strategy #66117 - #66415

Merged
yiguolei merged 2 commits into
apache:branch-4.1from
feiniaofeiafei:pick_adjust_eager_agg
Aug 4, 2026
Merged

branch-4.1:[enhance](eager-agg) adjust aggregation push down strategy #66117#66415
yiguolei merged 2 commits into
apache:branch-4.1from
feiniaofeiafei:pick_adjust_eager_agg

Conversation

@feiniaofeiafei

Copy link
Copy Markdown
Collaborator

picked from #66117

)

Issue Number: close #xxx

Related PR: #xxx

Problem Summary:
Adjust the “large join” threshold by increasing the build-side row-count
limit from 400K to 1M.
Allow aggregation to continue pushing down to the current join branch
when the opposite subtree is large or outputs String/Character types, so
that data participating in the join can be reduced earlier.
Tighten aggregation benefit evaluation: treat Group By keys with NDV >
rowCount / 10 as having extremely low aggregation benefit; for
multi-column Group By, skip aggregation pushdown if any key falls into
this category, avoiding low-benefit pushdown caused by high cardinality.
Take small broadcast join into account and propagate a “bottom small
broadcast join” marker in the pushdown context and apply stricter checks
on the probe side: reject pushdown when Group By column statistics are
unknown, or when any Group By key is estimated to reduce rows by less
than 1000×.
Extend aggregation pushdown traversal to support passing through
LogicalAggregate and LogicalIntersect nodes.
@hello-stephen

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@feiniaofeiafei

Copy link
Copy Markdown
Collaborator Author

run buildall

@hello-stephen

Copy link
Copy Markdown
Contributor

FE UT Coverage Report

Increment line coverage 68.18% (45/66) 🎉
Increment coverage report
Complete coverage report

@feiniaofeiafei

Copy link
Copy Markdown
Collaborator Author

run p0

1 similar comment
@feiniaofeiafei

Copy link
Copy Markdown
Collaborator Author

run p0

@hello-stephen

Copy link
Copy Markdown
Contributor

FE Regression Coverage Report

Increment line coverage 86.36% (57/66) 🎉
Increment coverage report
Complete coverage report

@hello-stephen

Copy link
Copy Markdown
Contributor

FE Regression Coverage Report

Increment line coverage 92.42% (61/66) 🎉
Increment coverage report
Complete coverage report

@yiguolei
yiguolei merged commit 28d350e into apache:branch-4.1 Aug 4, 2026
29 of 32 checks passed
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.

3 participants