You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains 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
This PR adds custom Dolt execution operators for lookup joins. When building an execution plan, we try to replace joinIter with a Dolt equivalent that inlines the key building and map get. This is a lot faster than repeatedly building the secondary iterator and materializing sql.Rows in-between lookups.
The main downside is that this PR hoists filters in join children to after materializing lookup join rows.
This brings index_join from 5.18 ms/query to 2.64 ms/q, which will be about 2.0x MySQL's latency.
This PR falls short of some aspiration goals:
We hoist table filters until after the final join row is built because we don't have a way to call scalar expressions on val.Tuple yet. There are edge case queries that might be dramatically slower because of this. To fix this, we could need to convert sql.Expression filters into a format that we could execute on val.Tuple KV pairs.
We do not yet try to to optimize consecutive lookup joins. I'm not sure if a materialization block would be better represented iteratively or recursively beyond a simple string of lookups. A lot of interfaces and indexing considerations to think about there.
Safety comments:
we fallback to GMS when lookup source/dest keys are not prolly.Encoding compatible
the source iterators are the same as what we used before, but without projection mapping to sql.Rows. The keyless iterator required a change to return duplicate rows at the KV layer (vs the sql layer).
the secondary iterators are a generalization of what we currently use, but return KV pairs instead of rows
projection mapping is the same but generalized to merge an arbitrary list of KV pairs after the join
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 PR adds custom Dolt execution operators for lookup joins. When building an execution plan, we try to replace
joinIter
with a Dolt equivalent that inlines the key building and map get. This is a lot faster than repeatedly building the secondary iterator and materializing sql.Rows in-between lookups.The main downside is that this PR hoists filters in join children to after materializing lookup join rows.
This brings
index_join
from 5.18 ms/query to 2.64 ms/q, which will be about 2.0x MySQL's latency.This PR falls short of some aspiration goals:
val.Tuple
yet. There are edge case queries that might be dramatically slower because of this. To fix this, we could need to convertsql.Expression
filters into a format that we could execute onval.Tuple
KV pairs.Safety comments:
prolly.Encoding
compatibleThere are extra tests here: dolthub/go-mysql-server#2593