opt: hoist uncorrelated equality subqueries

[mgartner]

opt: hoist uncorrelated equality subqueries

Subqueries that are in equality expressions with a variable are now
hoisted. When these expressions exist in a filter, hoisting the subquery
can allow the main query to plan a lookup join, rather than an
inefficient full-table scan.

For example, consider the table and query:

CREATE TABLE t (
  a INT,
  INDEX (a)
);

SELECT * FROM t WHERE a = (SELECT max(a) FROM t);

Prior to this commit, the query plan for this query required a full
table scan:

select
 ├── columns: a:1
 ├── scan t@t_a_idx
 │    ├── columns: a:1
 │    └── constraint: /1/2: (/NULL - ]
 └── filters
      └── eq
           ├── a:1
           └── subquery
                └── scalar-group-by
                     ├── columns: max:9
                     ├── scan t@t_a_idx,rev
                     │    ├── columns: a:5
                     │    ├── constraint: /5/6: (/NULL - ]
                     │    └── limit: 1(rev)
                     └── aggregations
                          └── const-agg [as=max:9, outer=(5)]
                               └── a:5

By hoisting the subquery, the full table scan is replaced with a lookup
join:

project
 ├── columns: a:1
 └── inner-join (lookup t@t_a_idx)
      ├── columns: a:1 max:9
      ├── key columns: [9] = [1]
      ├── scalar-group-by
      │    ├── columns: max:9
      │    ├── scan t@t_a_idx,rev
      │    │    ├── columns: a:5
      │    │    ├── constraint: /5/6: (/NULL - ]
      │    │    └── limit: 1(rev)
      │    └── aggregations
      │         └── const-agg [as=max:9, outer=(5)]
      │              └── a:5
      └── filters (true)

This hoisting is enabled by default, but can be disabled by setting the
optimizer_hoist_uncorrelated_equality_subqueries session setting to
false.

Fixes #83392
Informs #51820
Informs #93829
Informs #100855

Release note (performance improvement): Queries that have subqueries in
equality expressions are now more efficiently planned by the optimizer.

[cockroach-teamcity]

This change is 

[mgartner]

In the backports for this I'll default this session setting to false.

Here's some analysis of the performance improvements for a simple query that benefits from this change: https://gist.github.com/mgartner/9aa764ecbdb6d879d71863eb6b32b4c2

[mgartner]

Hold off on reviewing for now - there's some interesting test failures this has caused.

[mgartner]

This is currently blocked on #100915.

[mgartner]

The first three commits are from #100926 which should have fixed the broken builtin_function logic test, but it's still failing. No need to review just yet.

[mgartner]

The first three commits are from #101324 and #101327.

[DrewKimball]

Great idea! Do you have benchmark results for tpch Q15?

Reviewed 3 of 3 files at r1, 1 of 1 files at r2, 3 of 3 files at r3, 19 of 19 files at r4, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @rytaft)

[rytaft]

nice!

Do you have benchmark results for tpch Q15?

+1

Reviewed 3 of 3 files at r1, 1 of 1 files at r2, 3 of 3 files at r3, 19 of 19 files at r4, all commit messages.
Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @mgartner)

[mgartner]

Do you have benchmark results for tpch Q15?

How do I run the TPC-H benchmark?

I ran q15 manually in a demo on my GCE worker, and its ~5% slower than before this commit. Before it took ~6.3s and not it takes ~6.6s. It's not super obvious from the statement bundles why it's slower - it seems like it should be faster based on the query plan. And most of the time in both cases is spent on index-joins - so q15 would be best optimized with a STORING index to eliminate them. That'd have a significantly greater impact than this 5% regression. So I think this is fine. What do you all think?

Master stmt-bundle: https://gist.github.com/mgartner/3ce71bb0d8861011820e05b11bf5391e
Hoist subquery stmt-bundle: https://gist.github.com/mgartner/f9170879a8bc1a24a82f44979c3be4cd

Reviewable status: complete! 0 of 0 LGTMs obtained (and 2 stale) (waiting on @DrewKimball and @rytaft)

[rytaft]

Running queries manually is how I normally check for TPC-H regressions. How many times did you run the query? 5% seems small enough that it could just be noise. In any case, I'm not too concerned.

Regarding a STORING index -- I'm not sure what's allowed according to the spec, but if it's legal, I'm all for it (in a separate PR, obviously).

Reviewed 8 of 8 files at r5, all commit messages.
Reviewable status: complete! 0 of 0 LGTMs obtained (and 2 stale) (waiting on @mgartner)

[mgartner]

I don't think it was noise because it was consistently ~5% slower when run multiple times in multiple demos. I'm not too concerned about the 5% either.

[mgartner]

I'm going to go ahead and merge. TFTRs!

bors r+

[craig]

Build succeeded:

• Bazel Essential CI (Cockroach)

[blathers-crl]

Encountered an error creating backports. Some common things that can go wrong:

1. The backport branch might have already existed.
2. There was a merge conflict.
3. The backport branch contained merge commits.

You might need to create your backport manually using the backport tool.

---

error creating merge commit from 41fc214 to blathers/backport-release-22.2-100881: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict []

you may need to manually resolve merge conflicts with the backport tool.

Backport to branch 22.2.x failed. See errors above.

---

error creating merge commit from 41fc214 to blathers/backport-release-23.1.0-100881: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict []

you may need to manually resolve merge conflicts with the backport tool.

Backport to branch 23.1.0 failed. See errors above.

---

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}