Re: plan shape work

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alexandra Wang <alexandra(dot)wang(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "bruce(at)momjian(dot)us" <bruce(at)momjian(dot)us>, lepihov(at)gmail(dot)com
Subject: Re: plan shape work
Date: 2025-09-11 18:19:40
Message-ID: 1814222.1757614780@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> As you can see, the set of outer joins calculated at the same join can
> vary depending on the join order. What I suggested is to record this
> information in JoinPaths (or maybe also in Join plan nodes so that
> get_scanned_rtindexes can collect it) for the assertion.

I do not think this is correct, or at least it's not the most useful
way to think about it. As I stated earlier, each join plan node that
is doing a non-inner join has a unique corresponding outer-join RTE
that describes what it's doing. The point that you are making is
that if we've applied identity 3 to swap the order of two outer
joins, then we can't claim that the output of the lower plan node is a
fully-correct representation of the semantics of the join that it's
doing: there may be values that should have gone to NULL but won't
until after the upper plan node processes the rows.

If we're going to attach more labeling to the plan nodes, I'd
prefer to do what I suggested and label the nodes with the specific
outer join that they think they are implementing. With Richard's
proposal it will remain impossible to tell which node is doing what.

While I've still not worked through the details, it might be that
we can't implement my desire to make setrefs.c's nullingrels
checks exact unless we *also* store the bitmap sets that Richard
is proposing. I don't know if it's worth carrying two new fields
in order to make that work.

I don't entirely buy that Richard's proposed assertion is worth
doing: I think I agree with Robert's original opinion that it's
redundant. I do think that tightening the nullingrels checks
would be useful.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-09-11 18:39:14 Re: Conflict detection for update_deleted in logical replication
Previous Message Pierrick 2025-09-11 18:05:32 Re: Only one version can be installed when using extension_control_path