From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kirill Reshke <reshkekirill@gmail.com>
cc: pingw33n@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18751: Sub-optimal UNION ALL plan
In-reply-to: 
 <CALdSSPg3Dvw1oy+AJgUX15hDgFHYkjt7w5gGfVABt1vbSNewUg@mail.gmail.com>
References: <18751-887c7bf4e67e65a7@postgresql.org>
 <CALdSSPg3Dvw1oy+AJgUX15hDgFHYkjt7w5gGfVABt1vbSNewUg@mail.gmail.com>
Comments: In-reply-to Kirill Reshke <reshkekirill@gmail.com>
	message dated "Mon, 23 Dec 2024 19:24:40 +0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1347037.1734967136.1@sss.pgh.pa.us>
Date: Mon, 23 Dec 2024 10:18:56 -0500
Message-ID: <1347038.1734967136@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1347038.1734967136%40sss.pgh.pa.us>
Precedence: bulk

Kirill Reshke <reshkekirill@gmail.com> writes:
> I reproduced this on REL_16_STABLE, HEAD & REL_13_STABLE, so this is
> not really a bug, just a missing optimization?

Yeah.  I believe what is happening is that the addition of the WHERE
clause forces the second sub-SELECT to be planned as an independent
query.  And that level of planning has no idea that it might be
useful to produce a result ordered by "t", so it doesn't generate
a sub-plan that can do that.  Then the best that the outer level
can do is sort after-the-fact.

You could work around this by writing the second sub-SELECT like

	(select * from t2 where ... order by t)

			regards, tom lane