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
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 |