Skip to content

index join physicalization should follow the prop pushdown requirement mechanism #60106

@AilinKid

Description

@AilinKid

Enhancement

Image

Currently, logical join physicalization is embedded in the logical interface under the name findBestTask()... Like, when we do the physical enumeration of logic join, the first option is hashJoin, then we enumerate a physical hash join singleton here(default without any physicalized child). Then, we recursively dig down into the logical child, say we saw the projection here, then we enumerate the physical options for this logical projection according to the pushed down prop required and merged by its parent and ancestors.

While an index join breaks this loop, when we enumerate an physical index join, current tidb will assert some inner child pattern in current logical join's logic, then traverse down the asserted inner sub-tree, and build them up completely with undetermined ranges embedded in the underlying tableScan or indexScan (so-called index usage driven when probing rows). And the returned index-join's the inner side has already done its physicalization stuff, why bother to step into findBestTask interface again where the red lined commented in the picture.

Actually, this special workflow can be built with normal prop requirement mechanism, when an index join is enumerated, we build a rough physical index join as well with special index join runtime prop required inside. When we dig into the logical children, we should only handle this special index join runtime prop within those asserted inner pattern logical operator, while for those not, we can just refuse to build the inner physical task for them.

That's all the ideas, since the index join pattern covers more than thousands of lines of code, it needs a familiarity of all the index join building logic, and migrate all these logic into the prop requirement mechanism. Thank you for reading to the end. Thx again.

Sub-issues

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions