-
Notifications
You must be signed in to change notification settings - Fork 6k
Description
Enhancement
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.