Aleksandr Efimov has posted comments on this change. ( http://gerrit.cloudera.org:8080/24592 )
Change subject: IMPALA-15189: Support HBO for SortNode cardinality ...................................................................... Patch Set 6: (1 comment) http://gerrit.cloudera.org:8080/#/c/24592/6/fe/src/main/java/org/apache/impala/planner/DistributedPlanner.java File fe/src/main/java/org/apache/impala/planner/DistributedPlanner.java: http://gerrit.cloudera.org:8080/#/c/24592/6/fe/src/main/java/org/apache/impala/planner/DistributedPlanner.java@1352 PS6, Line 1352: lowerTopN.setTopNMergeParent(upperTopN); `lowerTopN` has already run `init()` and `computeStats()` before this split, while it was still considered a final TopN, so it can already hold the final HBO cardinality with `hasHboCard_ = true`. The exchange is then initialized from that value before this relationship is set. Assigning `topNMergeParent_` here only changes future `computeStats()` and storage decisions; nothing recomputes the lower node or the exchange. The final plan can therefore keep `(from HBO)` on the local TopN and use the merged whole-query cardinality as its local/exchange estimate, contrary to the final-node-only rule in `SortNode.computeStats()`. Could we mark the lower TopN before the exchange is initialized, or recompute lower → exchange → upper after setting the relationship? Please add a split analytic TopN test with an HBO hit that verifies the lower node does not retain the HBO annotation/cardinality and the exchange uses the recomputed estimate. -- To view, visit http://gerrit.cloudera.org:8080/24592 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: Impala-ASF Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: Ib829887a91593bee124d56e661e714575fe3be97 Gerrit-Change-Number: 24592 Gerrit-PatchSet: 6 Gerrit-Owner: Quanlong Huang <[email protected]> Gerrit-Reviewer: Aleksandr Efimov <[email protected]> Gerrit-Reviewer: Impala Public Jenkins <[email protected]> Gerrit-Reviewer: Quanlong Huang <[email protected]> Gerrit-Comment-Date: Mon, 31 Aug 2026 17:10:12 +0000 Gerrit-HasComments: Yes
