From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
cc: Andrey Lepikhov <a.lepikhov@postgrespro.ru>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Optimization issue of branching UNION ALL
In-reply-to: <1800456.1671680935@sss.pgh.pa.us>
References: <703c09a2-08f3-d2ec-b33d-dbecd62428b8@postgrespro.ru>
 <1788831.1671673839@sss.pgh.pa.us>
 <CAMbWs49fj701dxtmo9A7e+Bu_aR1xyLNPL4dPG+W0cT43QKgyg@mail.gmail.com>
 <1800456.1671680935@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Wed, 21 Dec 2022 22:48:55 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1803394.1671682466.1@sss.pgh.pa.us>
Date: Wed, 21 Dec 2022 23:14:26 -0500
Message-ID: <1803395.1671682466@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1803395.1671682466%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Richard Guo <guofenglinux@gmail.com> writes:
>> I noticed we also check 'parse->hasSubLinks' when we fix PHVs and
>> AppendRelInfos in pull_up_simple_subquery.  I'm not sure why we have
>> this check.  It seems not necessary.

> Yeah, I was wondering about that too ... maybe it was important
> in some previous state of the code?  I didn't do any archeology
> though.

After a bit of "git blame"-ing, it appears that that hasSubLinks
check was introduced in e006a24ad, which added a FlattenedSubLink
node type and needed to fix them up here:

+	 * We also have to fix the relid sets of any FlattenedSubLink nodes in
+	 * the parent query.  (This could perhaps be done by ResolveNew, but it

Then when I got rid of FlattenedSubLink in e549722a8, I neglected
to remove that check.  So I think maybe we don't need it, but I've
not tested.

			regards, tom lane