Reuse existing columns as discriminators#1247
Merged
Merged
Conversation
- In `expandSums` we now check for a suitable existing column in the
type of the join side to expand, and use this as the discriminator
instead of generating an additional column that always leads to a
subquery in SQL ("select 1, ..."). Suitable columns must be of a
primitive non-Option type. Primary keys are preferred over other
fields and those over computed columns. A conditional expression in
the wrapping Bind converts the column to the proper discriminator
type `Option[Int]`.
- These conditional expressions are eliminated in `hoistClientOps` if
they occur at the top level, passing the substitute discriminator
directly to the client side.
- A more flexible `IsDefinedResultConverter` is used for reading
discriminator columns of any Option type (only NULL vs non-NULL
matters). JdbcProfile uses a specialized, fused version.
- Computing the new StructNodes in `flattenProjections` now removes
duplicate definitions, except at the top level (where the projection
has to match the translated top-level type) and directly below a
Union (where both sides have to match up).
- `hoistClientOps` can now pull operations out of the non-Option sides
of joins which is required for avoiding subqueries in the case of
nested outer joins.
Tests in NewQuerySemanticsTest.testNewFusion, UnionTest.testBasicUnions.
Fixes #1241.
An important take-away from these improvements is that it is generally cheaper to broadly discard Path types when a NominalType has been invalidated and rely on inference to rebuild them instead of performing expensive type transformations. Even with the extra transformations for the improved discriminator column handling, performance is now >30% better than in 3.0.
Member
Author
|
This could still use some peephole optimization of the 3VL shenanigans that can remain in the join condition when using nested outer joins: |
- A new compiler phase `optimizeScalar` performs the required local optimizations to eliminate unnecessary null checks arising from outer joins after `expandSums`. - `expandSums` now keeps track of paths referenced within OptionApply nodes in Join and Filter predicates. These are preferred over other fields when picking a discriminator column for an outer join. The goal is to avoid NVL2 checks of the discriminator column in Join and Filter conditions (where this could prevent the use of an index). In the long term this may not be enough. A more complex alternative would be to pick *all* possible discriminators in `expandSums` and narrow them down to the best one in a later phase on a case by case basis.
Member
Author
|
Done. |
szeiger
added a commit
that referenced
this pull request
Aug 24, 2015
Reuse existing columns as discriminators
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
1 participant
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.
Plus some more performance improvements. Fixes #1241.