Skip to content

[opt](dphyper)optimize dphyper's statistics calculation (#64559) - #68204

Draft
starocean999 wants to merge 1 commit into
apache:branch-4.2from
starocean999:b42_64559
Draft

starocean999 wants to merge 1 commit into
apache:branch-4.2from
starocean999:b42_64559

Conversation

@starocean999

Copy link
Copy Markdown
Contributor

pick #64559

What problem does this PR solve?

Issue Number: close #xxx

Related PR: #xxx

Problem Summary:

Release note

None

Check List (For Author)

  • Test

    • Regression test
    • Unit Test
    • Manual test (add detailed scripts or steps below)
    • No need to test or manual test. Explain why:
      • This is a refactor/code format and no logic has been changed.
      • Previous test can cover this change.
      • No code files have been changed.
      • Other reason
  • Behavior changed:

    • No.
    • Yes.
  • Does this need documentation?

    • No.
    • Yes.

Check List (For Reviewer who merge this PR)

  • Confirm the release note
  • Confirm test cases
  • Confirm document
  • Add branch pick label

Problem Summary:
After DPHyp join enumeration copies projected join alternatives into the
memo, the memo statistics are stale — DPHyp uses a lightweight heuristic
cost model that does not produce accurate row counts or column
distributions.  Without a full statistics refresh, the subsequent
cascades optimization phase (OptimizeGroupJob) sees incorrect costs and
can produce suboptimal plans.

This PR introduces MemoStatsAndCostRecomputer, a bottom-up statistics
and cost recomputation pass that runs after DPHyp and before cascades
optimization.  It re-estimates logical row counts for every memo group,
aggregates them according to a configurable policy, and rebuilds
physical costs from the refreshed statistics.

Key changes:

1. MemoStatsAndCostRecomputer (new)
   - Bottom-up logical row-count re-estimation for every memo group.
   - Trust-join-count aggregation policy: scores each candidate
     expression by counting joins whose equal-join predicates have
     high-confidence (ndv/rowCount > 0.9) column statistics, keeping
     only the candidates with the most trusted joins.
   - Per-group isStatsReliable tracking that stays consistent with the
     selected/aggregated statistics instead of leaking from the last
     candidate estimated in the loop.
   - Project-group stats divergence protection: when two LogicalProject
     alternatives diverge by >1000x in row count, the stats from the
     currently-best PhysicalProject are preserved to avoid a misleading
     aggregate (average/median).
   - Two-pass logical re-estimation for CTE queries so consumers can
     settle on refreshed producer stats.
   - Physical-cost recomputation: clears and rebuilds per-group
     lowest-cost-plan tables from the refreshed statistics.

2. countTrustJoins / getGroupTrustJoinCount
   - Deterministic trust-join scoring: replaced child.getFirstLogical-
     Expression() (memo-insertion-order dependent) with a per-group max
     across all alternatives, memoized via groupTrustJoinCountCache.
   - Cache is cleared before each logical re-estimation pass so CTE
     producer stat changes are reflected.

3. hasTrustableEqualCondition (JoinEstimation)
   - Rejects unknown column stats (ColumnStatistic.UNKNOWN) before the
     NDV-ratio check.  Unknown stats carry ndv=1, which could falsely
     pass the >0.9 threshold on one-row tables.

4. GraphSimplifier cache isolation
   - deriveStats and calCost now snapshot and restore their caches
     between alternative join-order evaluations, preventing the second
     alternative from reading column statistics derived for the first
     alternative's join order.

5. DPHyp shape-check regression tests
   - TPC-DS SF1000: 99 queries
   - TPC-H SF1000: 22 queries

(cherry picked from commit 9e45962)
@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?

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.

2 participants