Skip to content
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

opt: Add pruning rule for columns on the right side of Semi/Anti joins #38704

Closed
andy-kimball opened this issue Jul 4, 2019 · 0 comments · Fixed by #39472
Closed

opt: Add pruning rule for columns on the right side of Semi/Anti joins #38704

andy-kimball opened this issue Jul 4, 2019 · 0 comments · Fixed by #39472
Assignees
Labels
C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) E-starter Might be suitable for a starter project for new employees or team members.
Milestone

Comments

@andy-kimball
Copy link
Contributor

Consider this schema and query:

create table t1 (a int primary key, b int);
create table t2 (c int primary key, d int);
explain (opt,types) select * from t1 where exists(select * from t2 where c=a);

The optimized query uses a semi-join:

semi-join (merge)
 ├── columns: a:1(int!null) b:2(int)
 ├── left ordering: +1
 ├── right ordering: +3
 ├── scan t1
 │    └── columns: a:1(int!null) b:2(int)
 ├── scan t2
 │    └── columns: c:3(int!null) d:4(int)
 └── filters (true)

However, the d column can be pruned here, since it is not used by the join, and is not returned as an output column.

We should add a new prune_cols.opt rule that prunes unused columns on the right side of a Semi or Anti join (assuming the columns are in the PruneCols rule property set).

@andy-kimball andy-kimball added the E-starter Might be suitable for a starter project for new employees or team members. label Jul 4, 2019
@awoods187 awoods187 added the C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) label Jul 8, 2019
@RaduBerinde RaduBerinde added this to the 19.2 milestone Jul 8, 2019
ridwanmsharif pushed a commit to ridwanmsharif/cockroach that referenced this issue Aug 8, 2019
Fixes cockroachdb#38704.

This change adds a PruneSemiAntiJoinRightCols to prune
columns in the RHS of a semi/anti join. Alternatively,
we could just tag the PruneJoinRightCols rule as higher
priority to achieve the same effect (previously that rule
was never triggered because the `EliminateProjects` rule
would fire and remove the projections after
`PruneJoinLeftCols` rule is applied). I prefer this rule
because it avoids require an ordering of transformations.

Release note: None
ridwanmsharif pushed a commit to ridwanmsharif/cockroach that referenced this issue Aug 15, 2019
Fixes cockroachdb#38704.

This change adds a PruneSemiAntiJoinRightCols to prune
columns in the RHS of a semi/anti join. Alternatively,
we could just tag the PruneJoinRightCols rule as higher
priority to achieve the same effect (previously that rule
was never triggered because the `EliminateProjects` rule
would fire and remove the projections after
`PruneJoinLeftCols` rule is applied). I prefer this rule
because it avoids requiring an ordering of transformations.

Release note: None
craig bot pushed a commit that referenced this issue Aug 16, 2019
39464: exec: handle some mixed type comparison expressions r=rafiss a=rafiss

This adds support for int-int comparisons and float-float comparisons
(of different sizes), as well as various string comparisons. This
is necessary to support TPC-H queries 7, 16, 19, and 21 (though there
are still other issues to address before those are fully supported).

There is some refactoring here so that as a next step we can support
comparisons between different types entirely (e.g. int-decimal).

touches #39189

Release note: None

39472: opt: prune RHS of a semi/anti join r=ridwanmsharif a=ridwanmsharif

Fixes #38704.

This change adds a PruneSemiAntiJoinRightCols to prune
columns in the RHS of a semi/anti join. Alternatively,
we could just tag the PruneJoinRightCols rule as higher
priority to achieve the same effect (previously that rule
was never triggered because the `EliminateProjects` rule
would fire and remove the projections after
`PruneJoinLeftCols` rule is applied). I prefer this rule
because it avoids requiring an ordering of transformations.

Release note: None

Co-authored-by: Rafi Shamim <[email protected]>
Co-authored-by: Ridwan Sharif <[email protected]>
@craig craig bot closed this as completed in #39472 Aug 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) E-starter Might be suitable for a starter project for new employees or team members.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants