Dataflow: Fix join in fwdFlowRead (take 2)#12072
Merged
MathiasVP merged 2 commits intogithub:mainfrom Feb 6, 2023
Merged
Conversation
…of the Content-to-Ap relation.
d3eda11 to
67d4ed5
Compare
Contributor
Author
|
cc @MathiasVP |
There was a problem hiding this comment.
CodeQL found more than 10 potential problems in the proposed changes. Check the Files changed tab for more details.
Contributor
|
Indeed, this fixes the join-order issue we observed on Pipeline order_500000 for DataFlowImpl3#c0e9fca6::MkStage#Stage2#::Stage#Stage3Param#::fwdFlowRead#9#fffffffff#reorder_0_1_8_2_3_4_5_6_7@3338d1w4 was evaluated in 178 iterations totaling 86ms (delta sizes total: 3254).
35708 ~0% {7} r1 = SCAN DataFlowImpl3#c0e9fca6::MkStage#Stage2#::Stage#Stage3Param#::fwdFlow#8#ffffffff#prev_delta OUTPUT In.5, In.0, In.1, In.2, In.3, In.4, In.7
10590 ~0% {8} r2 = JOIN r1 WITH DataFlowImpl3#c0e9fca6::Stage3Param::getHeadContent#1#ff ON FIRST 1 OUTPUT Lhs.1, Rhs.1, Lhs.6, Lhs.2, Lhs.3, Lhs.4, Lhs.5, Lhs.0
3254 ~0% {9} r3 = JOIN r2 WITH DataFlowImpl3#c0e9fca6::MkStage#Stage2#::Stage#Stage3Param#::readStepCand#5#fffff_01423#join_rhs ON FIRST 3 OUTPUT Lhs.0, Lhs.3, Lhs.4, Lhs.5, Lhs.6, Lhs.7, Lhs.2, Rhs.3, Rhs.4
3254 ~0% {9} r4 = r3 AND NOT DataFlowImpl3#c0e9fca6::MkStage#Stage2#::Stage#Stage3Param#::fwdFlowRead#9#fffffffff#reorder_0_1_8_2_3_4_5_6_7#prev(Lhs.5, Lhs.7, Lhs.6, Lhs.0, Lhs.8, Lhs.1, Lhs.2, Lhs.3, Lhs.4)
3254 ~0% {9} r5 = SCAN r4 OUTPUT In.5, In.7, In.6, In.0, In.8, In.1, In.2, In.3, In.4
return r5
Pipeline order_500000 for DataFlowImpl3#c0e9fca6::MkStage#Stage3#::Stage#Stage4Param#::fwdFlowRead#9#fffffffff#reorder_0_1_8_2_3_4_5_6_7@bc0f31wo was evaluated in 216 iterations totaling 129ms (delta sizes total: 4676).
93351 ~1% {7} r1 = SCAN DataFlowImpl3#c0e9fca6::MkStage#Stage3#::Stage#Stage4Param#::fwdFlow#8#ffffffff#prev_delta OUTPUT In.5, In.0, In.1, In.2, In.3, In.4, In.7
65533 ~1% {9} r2 = JOIN r1 WITH DataFlowImpl3#c0e9fca6::Stage4Param::getHeadContent#1#ff ON FIRST 1 OUTPUT Lhs.1, Rhs.1, Rhs.1, Lhs.6, Lhs.2, Lhs.3, Lhs.4, Lhs.5, Lhs.0
4676 ~0% {9} r3 = JOIN r2 WITH DataFlowImpl3#c0e9fca6::MkStage#Stage3#::Stage#Stage4Param#::readStepCand#5#fffff_01243#join_rhs ON FIRST 4 OUTPUT Lhs.0, Lhs.4, Lhs.5, Lhs.6, Lhs.7, Lhs.8, Lhs.3, Lhs.1, Rhs.4
4676 ~0% {9} r4 = r3 AND NOT DataFlowImpl3#c0e9fca6::MkStage#Stage3#::Stage#Stage4Param#::fwdFlowRead#9#fffffffff#reorder_0_1_8_2_3_4_5_6_7#prev(Lhs.5, Lhs.7, Lhs.6, Lhs.0, Lhs.8, Lhs.1, Lhs.2, Lhs.3, Lhs.4)
4676 ~1% {9} r5 = SCAN r4 OUTPUT In.5, In.7, In.6, In.0, In.8, In.1, In.2, In.3, In.4
return r5
Pipeline order_500000 for DataFlowImpl3#c0e9fca6::MkStage#Stage4#::Stage#Stage5Param#::fwdFlowRead#9#fffffffff#reorder_0_1_8_2_3_4_5_6_7@dac2c2w3 was evaluated in 177 iterations totaling 78ms (delta sizes total: 3327).
32164 ~1% {7} r1 = SCAN DataFlowImpl3#c0e9fca6::MkStage#Stage4#::Stage#Stage5Param#::fwdFlow#8#ffffffff#prev_delta OUTPUT In.5, In.0, In.1, In.2, In.3, In.4, In.7
7997 ~0% {9} r2 = JOIN r1 WITH DataFlowImpl3#c0e9fca6::Stage5Param::getHeadContent#1#ff ON FIRST 1 OUTPUT Lhs.1, Rhs.1, Rhs.1, Lhs.6, Lhs.2, Lhs.3, Lhs.4, Lhs.5, Lhs.0
3327 ~0% {9} r3 = JOIN r2 WITH DataFlowImpl3#c0e9fca6::MkStage#Stage4#::Stage#Stage5Param#::readStepCand#5#fffff_01243#join_rhs ON FIRST 4 OUTPUT Lhs.0, Lhs.4, Lhs.5, Lhs.6, Lhs.7, Lhs.8, Lhs.3, Lhs.1, Rhs.4
3327 ~0% {9} r4 = r3 AND NOT DataFlowImpl3#c0e9fca6::MkStage#Stage4#::Stage#Stage5Param#::fwdFlowRead#9#fffffffff#reorder_0_1_8_2_3_4_5_6_7#prev(Lhs.5, Lhs.7, Lhs.6, Lhs.0, Lhs.8, Lhs.1, Lhs.2, Lhs.3, Lhs.4)
3327 ~0% {9} r5 = SCAN r4 OUTPUT In.5, In.7, In.6, In.0, In.8, In.1, In.2, In.3, In.4
return r5 |
Contributor
Author
|
dca looks uneventful |
MathiasVP
approved these changes
Feb 6, 2023
Contributor
MathiasVP
left a comment
There was a problem hiding this comment.
LGTM! Thanks for properly fixing this 🙂.
MathiasVP
approved these changes
Feb 6, 2023
Contributor
MathiasVP
left a comment
There was a problem hiding this comment.
LGTM! Thanks for properly fixing this 🙂.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This ought to be a proper fix, replacing #12009.
The relation between the
Aptype andContentis a necessary constraint when traversing a read step. This relation is mostly functional fromAptoContent, except for stage 2 where it is a trivial cartesian product. This has meant that we've until recently been able to rely on this functionality when designing the join-order. However, the newly introduced stage 3 broke this (approximated contents meant that the relation was mostly functional in the opposite direction), so in order for us to come up with a join-order that works for all stages I've introduced an intermediate type to represent the precision level ofContentin the stage-dependentAptype. That way we can decompose theAp-to-Contentrelation into two relations with stage-independent functionality directions.