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