Re: BUG #18751: Sub-optimal UNION ALL plan

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: pingw33n(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18751: Sub-optimal UNION ALL plan
Date: 2024-12-24 02:57:31
Message-ID: e405c80a-49ee-4a37-827d-d53b5189ad3e@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 12/23/24 22:18, Tom Lane wrote:
> Kirill Reshke <reshkekirill(at)gmail(dot)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.
I didn't discover the case deeply yet, but it looks similar to your
improvement of CTEs in a65724d.
BTW, SQL Server also uses bad variant of the plan for this query, or I
just don't know how to cook that soup properly.

--
regards, Andrei Lepikhov

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2024-12-24 03:46:58 Re: BUG #18751: Sub-optimal UNION ALL plan
Previous Message Laurenz Albe 2024-12-23 17:39:33 Re: Commit 5a2fed911a broke parallel query