Horton

Re: Optimization issue of branching UNION ALL

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
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>
Date: 2022-12-22T04:14:26Z
Lists: pgsql-hackers 
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

Commits

  1. Avoid O(N^2) cost when pulling up lots of UNION ALL subqueries.

  2. Add some recursion and looping defenses in prepjointree.c.