From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
Cc: Andrey Lepikhov <a.lepikhov@postgrespro.ru>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware)
Date: Mon, 20 Mar 2023 12:21:49 -0400
Message-ID: <945557.1679329309@sss.pgh.pa.us> (raw)
In-Reply-To: <CAMbWs4-sZzwdOhhvX1KoQc5HXwkSKoRbcOg4eTtc_dn2sV+ndg@mail.gmail.com>
References: <0b819232-4b50-f245-1c7d-c8c61bf41827@postgrespro.ru>
<CAMbWs4_HJNuLv9HDReEBDrQrCPV-uqpVOecoJkurprnY+Do9Fg@mail.gmail.com>
<CAMbWs4_8EZU4DetHyZGm1CwCxUhBdWpRnA9dtM-Z82i=bVKA6A@mail.gmail.com>
<CAMbWs4_XcPHqc=A=36cxvJRhkjAgEeJtOFLOnBPEfQYGqnGOCw@mail.gmail.com>
<efb33bee-145d-95a8-1048-2e7b8f282e2c@postgrespro.ru>
<CAMbWs48FHw_tTXSbA-_MPaeu7S7JCt6Xs-gxwkx=pvLiwC6eTg@mail.gmail.com>
<c69bd07e-1175-10da-9ac0-4bfe59235ac2@postgrespro.ru>
<402433.1677524538@sss.pgh.pa.us>
<2663884e-769a-b298-55b0-014c5a1ee55c@postgrespro.ru>
<524303.1677538463@sss.pgh.pa.us>
<999171.1677611407@sss.pgh.pa.us>
<CAMbWs4-_KdVEJ62o6KbtA+_KJnQa7WZCc48VsPQ9in6TSN0Kxg@mail.gmail.com>
<CAMbWs49J+VXT6KA2nmjdrm_i4tt5B1PRP0uge0F52MMV9OdvFQ@mail.gmail.com>
<1903666.1677770838@sss.pgh.pa.us>
<CAMbWs4-sZzwdOhhvX1KoQc5HXwkSKoRbcOg4eTtc_dn2sV+ndg@mail.gmail.com>
[ sorry for slow response ]
Richard Guo <guofenglinux@gmail.com> writes:
> On Thu, Mar 2, 2023 at 11:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> What's feeling like it might be the best thing is to go ahead and
>> syntactically convert to the second form of identity 3 as soon as
>> we've determined it's applicable, so that upper C Vars are always
>> marked with both OJ relids. Not sure how much work is involved
>> there.
> I'm thinking something that once we've determined identity 3 applies in
> make_outerjoininfo we record information about how to adjust relids for
> upper quals and store this info in all upper JoinTreeItems. Then
> afterwards in distribute_qual_to_rels we check all this info stored in
> current JoinTreeItem and adjust relids for the qual accordingly.
> The info we record should consist of two parts, target_relids and
> added_relids. Vars and PHVs in quals that belong to target_relids
> should be adjusted to include added_relids.
> Following this idea I come up with attached patch (no comments and test
> cases yet). It fixes the presented case and passes check-world. Before
> finishing it I'd like to know whether this idea works. Any comments are
> appreciated.
This doesn't look hugely promising to me. We do need to do something
like "Vars/PHVs referencing join X now need to also reference join Y",
but I think we need to actually change the individual Vars/PHVs not
just fake it by hacking the required_relids of RestrictInfos. Otherwise
we're going to get assertion failures in setrefs.c about nullingrel
sets not matching up.
Also, in addition to upper-level quals, we need to apply the same
transformation to the query's targetlist and havingQual if anyway
(and perhaps also mergeActionList, not sure).
So the idea that I had was to, once we detect that X commutes with Y,
immediately call a function that recurses through the relevant parts
of root->parse and performs the required nullingrels updates. This'd
result in multiple transformation traversals if there are several
commuting pairs of joins, but I doubt that that would really pose a
performance problem. If it does, we could imagine splitting up
deconstruct_jointree still further, so that detection of commutable
OJs happens in a pass earlier than distribute_quals_to_rels, and then
we fix up Vars/PHVs throughout the tree in one scan done between those
passes. But an extra deconstruct recursion pass isn't free either, so
I don't want to do that unless we actually see a performance problem.
Assuming we don't do that but perform this transformation during
deconstruct_jointree phase 2, it'd be too late to modify quals of
already-processed join tree nodes, but that's fine because they
couldn't contain Vars needing adjustment. (We could exploit that
in an incomplete way by passing in the address of the current
JoinExpr, and not bothering to recurse below it.) There is code
roughly like this in prepjointree.c already --- in particular, we'd
need to steal its hack of mutating join quals but not the JoinExpr and
FromExpr nodes themselves, to avoid breaking the recursion-in-progress.
I can have a go at coding this, or you can if you'd like to.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, guofenglinux@gmail.com, a.lepikhov@postgrespro.ru, pgsql-bugs@lists.postgresql.org
Subject: Re: Clause accidentally pushed down ( Possible bug in Making Vars outer-join aware)
In-Reply-To: <945557.1679329309@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox