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>, Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware) |
Date: | 2023-05-18 13:28:33 |
Message-ID: | 3732983.1684416513@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> BTW, it seems that there is a minor thinko in the changes. In the
> outer-join removal logic, we use syn_xxxhand to compute the relid set
> for the join we are considering to remove. I think this might be not
> right, because the outer joins may not be performed in syntactic order.
No, I don't believe that. What we are interested in at this point is
the semantic effect (or lack of it) of the potentially-removable join.
It's fine to reason about that under the assumption that the joins will
be done in syntactic order. If later parts of the planner decide to
implement the joins in a different order, that cannot change the
conclusion about whether it's safe to remove a join --- otherwise,
either we were mistaken to remove the join, or the reordering logic
is wrong.
I prefer the code as it stands now because it helps to decouple the
join-removal reasoning from the join-reordering logic, limiting any
possible effect of bugs in the latter. (I think I might've had
some other reason for changing it as well, but can't reconstruct
that first thing in the morning.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Lakhin | 2023-05-18 14:00:00 | Re: BUG #17695: Failed Assert in logical replication snapbuild. |
Previous Message | Richard Guo | 2023-05-18 08:58:21 | Re: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware) |