Re: [HACKERS] CTE inlining

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: [HACKERS] CTE inlining
Дата
Msg-id CAHyXU0xcbctKzRoenpJL8fj01GDCy0KzmFCSus3qHAjOyB-bAA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] CTE inlining  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: [HACKERS] CTE inlining  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Re: [HACKERS] CTE inlining  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Список pgsql-hackers
On Wed, May 3, 2017 at 12:33 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> David Fetter wrote:
>
>> When we add a "temporary" GUC, we're taking on a gigantic burden.
>> Either we support it forever somehow, or we put it on a deprecation
>> schedule immediately and expect to be answering questions about it for
>> years after it's been removed.
>>
>> -1 for the GUC.
>
> Absolutely.
>
> So ISTM we have three choices:
>
> 1) we switch unmarked CTEs as inlineable by default in pg11.  What seems
> likely to happen for a user that upgrades to pg11 is that 5 out of 10
> CTE-using queries are going to become faster than with pg10, and they
> are going to be happy; 4 out of five are going to see no difference, but
> they didn't have to do anything about it; and the remaining query is
> going to become slower, either indistinguishably so (in which case they
> don't care and they remain happy because of the other improvements) or
> notably so, in which case they can easily figure where to add the
> MATERIALIZED option and regain the original performance.

+1 for option 1.  This change will be welcome for a large number of
queries, but forced materialization is a real need and I use it often.
This comes off as a very reasonable compromise in my opinion unless it
requires major coding gymnastics to implement.

merlin



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: [HACKERS] CTE inlining
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: [HACKERS] WITH clause in CREATE STATISTICS