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
Re: [HACKERS] CTE inlining |
Список | 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 по дате отправления: