Re: CTE Materialization

From: Дмитрий Иванов <firstdismay(at)gmail(dot)com>
To: Paul van der Linden <paul(dot)doskabouter(at)gmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: CTE Materialization
Date: 2021-12-09 03:26:38
Message-ID: CAPL5KHoH=+h0c9F8HMi7GCHnORdsy82+qUJvGhFx4PqNBfk_8w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Спасибо!
--
С уважением, Дмитрий!

ср, 8 дек. 2021 г. в 22:58, Paul van der Linden <paul(dot)doskabouter(at)gmail(dot)com
>:

> This one quite nicely explains it:
> https://stackoverflow.com/questions/14897816/how-can-i-prevent-postgres-from-inlining-a-subquery
>
> On Wed, Dec 8, 2021 at 3:14 AM David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
>> On Tue, Dec 7, 2021 at 6:40 PM Дмитрий Иванов <firstdismay(at)gmail(dot)com>
>> wrote:
>>
>>> I beg your pardon.
>>> The problem is more or less clear to me, but the solution is not. What
>>> does the "hack is to add an "offset 0" to the query" suggest? Thank you.
>>>
>>>
>> A subquery with a LIMIT clause cannot have where clause expressions in
>> upper parts of the query tree pushed down it without changing the overall
>> query result - something the planner is not allowed to do. For the hack,
>> since adding an actual LIMIT clause doesn't make sense you omit it, but
>> still add the related OFFSET clause so the planner still treats the
>> subquery as a LIMIT subquery. And since you don't want to skip any rows
>> you specify 0 for the offset.
>>
>> David J.
>>
>>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Avi Weinberg 2021-12-09 09:13:53 Identity/Serial Column In Subscriber's Tables
Previous Message Peter J. Holzer 2021-12-08 22:14:13 Re: performance expectations for table(s) with 2B recs