-
-
Notifications
You must be signed in to change notification settings - Fork 210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More join types #1280
More join types #1280
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly looks good, just a few comments
For future PRs, it's easier to review these when split into smaller functional chunks (although this wasn't egregious)
sql/analyzer/hoist_select_exists.go
Outdated
}) | ||
} | ||
|
||
// pluckCorrelatedExistsSubquery scans a filter for [note] WHERE EXISTS, and then attempts to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is [note]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
autocorrect i think, meant [NOT] WHERE EXISTS
sql/plan/join.go
Outdated
type JoinType uint16 | ||
|
||
const ( | ||
UnknownJoinType JoinType = iota // UnknownJoinType |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: generally speaking we name this kind of enum constant with the type first, so that all the possible values sort next to eachother
BinaryNode | ||
Cond sql.Expression | ||
Filter sql.Expression |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer cond, is there a particular reason you changed this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
filters are more mobile in the new join ordering algo, seems easier to just call them all filters. At some point i'd like to split these into a list of filters rather than an expression.JoinAnd(filters...)
, probably memoized, index selection doesn't have to be as painful as it is right now.
panic("join implementation should provide schema") | ||
} | ||
|
||
func constructNewJoin(base *joinBase) JoinNode { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Smart, I like it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:)
Add
FullOuterJoin
,SemiJoin
, andAntiJoin
.None of these new join nodes are safe for join ordering transformations yet. They are explicitly excluded from join planning.
The getField indexes for these three nodes' join conditions deserve more consideration. I excluded them from auto-fixup after manually correcting join condition get fields for the appropriate schemas.
FullOuterJoin
uses a union distinct execution operator, which is correct but a lot slower than a merge join-esque operator.SemiJoin
andAntiJoin
rearrange subquery expression scopes. I separateresolve
andfinalizeSubqueryExpressions
to perform decorrelation before predicate pushdown (where we were panicking on FixUpExpressions) and join ordering (we want to decorrelate scopes before join planning).Other: