Re: Making Vars outer-join aware

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>, "Finnerty, Jim" <jfinnert@amazon.com>
Date: 2022-11-16T22:02:41Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Re-allow INDEX_VAR as rt_index in ChangeVarNodes().

  2. Fix thinkos in have_unsafe_outer_join_ref; reduce to Assert check.

  3. Invent "join domains" to replace the below_outer_join hack.

  4. Do assorted mop-up in the planner.

  5. Make Vars be outer-join-aware.

  6. Invent "multibitmapsets", and use them to speed up antijoin detection.

  7. Add basic regression tests for semi/antijoin recognition.

  8. Improve performance of adjust_appendrel_attrs_multilevel.

  9. Refactor addition of PlaceHolderVars to joinrel targetlists.

  10. Use an explicit state flag to control PlaceHolderInfo creation.

  11. Make PlaceHolderInfo lookup O(1).

Attachments

Richard Guo <guofenglinux@gmail.com> writes:
> BTW, inner_join_rels can contain base Relids and OJ Relids.  Maybe we
> can revise the comments a bit for it atop deconstruct_recurse and
> make_outerjoininfo.  The same for the comments of qualscope, ojscope and
> outerjoin_nonnullable atop distribute_qual_to_rels.

Yeah.  I had an XXX comment about whether or not it was okay to
include OJs in inner_join_rels.  I took a second look and decided it's
fine, so I removed the XXX and updated these comments.

> The README mentions restriction_is_computable_at(), I think it should be
> clause_is_computable_at().

Right.  I think when I wrote that I was imagining that there'd be a
wrapper function specifically concerned with RestrictInfos, but in the
event it didn't seem useful.  There's only one place that uses this,
namely subbuild_joinrel_restrictlist.

The cfbot is about to start complaining that this patchset doesn't apply
over e9e26b5e7, so here's a rebase.

			regards, tom lane