Horton

Re: Making Vars outer-join aware

Anton A. Melnikov <aamelnikov@inbox.ru>

View thread
From: "Anton A. Melnikov" <aamelnikov@inbox.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Richard Guo <guofenglinux@gmail.com>, pgsql-hackers@lists.postgresql.org, "Finnerty, Jim" <jfinnert@amazon.com>
Date: 2023-07-23T12:20:21Z
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).

On 08.06.2023 19:58, Tom Lane wrote:
> I think the right thing here is not either of your patches, but
> to tweak adjust_relid_set() to not fail on negative oldrelid.
> I'll go make it so.

Thanks! This fully solves the problem with ChangeVarNodes() that i wrote above.


> Hmm.  That implies that you're changing plan data structures around after
> setrefs.c, which doesn't seem like a great design to me --- IMO that ought
> to happen in PlanCustomPath, which will still see the original varnos.

My further searchers led to the fact that it is possible to immediately set the
necessary varnos during custom_scan->scan.plan.targetlist creation and leave the
сustom_scan->custom_scan_tlist = NIL rather than changing them later using ChangeVarNodes().
This resulted in a noticeable code simplification.
Thanks a lot for pointing on it!

Sincerely yours,

-- 
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company