Re: [HACKERS] CTE inlining
От | Julien Rouhaud |
---|---|
Тема | Re: [HACKERS] CTE inlining |
Дата | |
Msg-id | 5582f012-1f79-695f-1aad-9b95cb558c0e@dalibo.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] CTE inlining (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Список | pgsql-hackers |
On 04/05/2017 08:34, Petr Jelinek wrote: > On 03/05/17 23:24, Merlin Moncure wrote: >> 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. >> > > +1 to this > +1 too -- Julien Rouhaud http://dalibo.com - http://dalibo.org
В списке pgsql-hackers по дате отправления: