Java: Improve a couple of join-orders #20127
Open
+53
−30
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.
3 commits fixing 3 join-orders:
closeCalled
code was quite tangled, which caused the optimiser to selectNOT #prev
before#prev_delta
. This is always bad, so the optimiser only does this when it's pushed sufficiently into a corner - usually due to excessive nesting. A little bit of untangling helped.getErasedRepr
inherently contains cartesian products, so the optimiser can't avoid them, which messes with its estimates. A slight refactor ensures that the CPs are with predicates of size 1 as they should be.fastTC
was being nicely transformed todoublyBoundedFastTC
by the optimiser, however thesource(t, n)
join represents a step with a huge fanout, so by including that in the graph the resulting bounded TC becomes orders of magnitude smaller.Tuple counts:
1.
Before
After:
Before:
After:
Before
After: