[
https://issues.apache.org/jira/browse/IMPALA-15312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110297#comment-18110297
]
Aleksandr Efimov commented on IMPALA-15312:
-------------------------------------------
There are no SelectNodes in the plan those numbers came from, so 24612 on its
own
does not touch it. The report still runs daily and today's profile has the same
shape: 516 plan nodes, 240 with "(from HBO)" - 120 scans and 120 aggregates -
against 90 hash joins, 31 unions and one TOP-N carrying nothing.
What holds that plan back is structure rather than a miss in the history. Every
one of the 31 unions, and both un-annotated aggregates, has a hash join
somewhere
below it, and a key is only built when every operand has one, so the join stops
everything above it. With the whole chain the ceiling here is 240 -> 364 of 516,
and it is 24426 at the bottom that opens it.
The chain also lands on the plan change from the earlier comment. Looking
through
the exchanges, the 90 joins split into 60 with an aggregate carrying an HBO
cardinality against a hash join carrying none, and 30 with two HBO scans, and
the
60 are exactly the outer joins that stopped being inverted. So the inversion
check
there is comparing a corrected number against an uncorrected one, and with join
cardinalities in place both sides move and those 60 decisions get taken again.
Whether they flip back I cannot say without running it.
SelectNodes do turn up elsewhere. Over about twelve hours of profile logs from
one coordinator - 3897 plans, 145848 plan nodes, 22% of them annotated today -
there are 1733 SELECT nodes, but only 11% of those have a fully keyed subtree
below, so most of them wait on the rest of the chain anyway. The same count for
the others: 21162 join nodes, 80% of them keyed below on their own; 3863 sort,
TOP-N and merging exchanges, 25%; 2692 analytic, near zero.
All of this is counted from profiles rather than measured against a build
carrying your patches, since I have no way to put one on that deployment, so it
is coverage arithmetic and not an A/B. Once the chain lands and the deployment
picks up a build with it, I can rerun the same A/B on that report and say what
the 60 joins did.
> Show when an HBO cardinality changed a plan decision
> ----------------------------------------------------
>
> Key: IMPALA-15312
> URL: https://issues.apache.org/jira/browse/IMPALA-15312
> Project: IMPALA
> Issue Type: Improvement
> Components: Frontend
> Reporter: Aleksandr Efimov
> Assignee: Aleksandr Efimov
> Priority: Major
>
> h3. Problem
> IMPALA-15236 puts the provenance of an HBO cardinality next to the number:
> the canonicalization strategy that matched, the hash key, the estimate the
> planner had computed on its own, and the ratio between the two. That answers
> where the number came from. It does not answer whether the number changed the
> plan.
> The two questions come apart. Decisions that consume cardinalities are cost
> based, so a corrected estimate can flip one while leaving the shape of the
> plan alone. Join inversion is the clearest case: {{Planner.invertJoins()}}
> inverts a join when {{isInvertedJoinCheaper()}} says so, and that check
> weighs the two children by cardinality, average row size and node count.
> Correct the build side and the verdict can flip, so a join that was planned
> inverted goes back. The number of joins does not change, the
> broadcast/partitioned mix does not change, and the operator histogram of the
> plan does not change - only the side each join builds on.
> This is not hypothetical. On an outer-join-heavy query, HBO correcting a
> build-side aggregate from a few thousand rows down to fourteen turned sixty
> joins back from RIGHT OUTER to LEFT OUTER, and a comparison of the two plans
> by operator counts reported them as the same plan.
> Answering "what did HBO do to this plan" today means running the query twice,
> once with {{use_hbo_stats=false}}, and diffing the two plans. On a report
> that runs for minutes that is a measurement exercise rather than debugging.
> h3. Proposed change
> Mark the nodes where the HBO substitution changed a planner decision, not
> only the estimate, in the plan and in the profile.
> Two directions, each with a cost worth weighing:
> * Plan twice under a debug query option and diff the results. Exact, and only
> paid for when someone asks for it.
> * Carry the pre-HBO estimate through the cardinality computation and
> re-evaluate the cost based decisions with it. No second planning pass, but it
> has to propagate: a node whose own key did not match can still get a
> different cardinality because a descendant matched, and
> {{PlanNode.cardinalityBeforeHbo_}} stays -1 on such a node, so a check that
> reads only that field reports no change where there was one.
> h3. Note for the comparison itself
> Plan node ids do not move when a join flips: they are handed out as nodes are
> constructed, before {{invertJoins()}} runs, and {{invertJoin()}} keeps the
> id. Exchange ids do move - {{DistributedPlanner.createHashJoinFragment()}}
> numbers the left child's exchange before the right child's, so an inversion
> swaps the two, and the merge aggregation takes the next id from the same
> counter. A diff keyed on node id therefore reports differences that are only
> numbering; comparing the whole-plan operator histogram separates them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
