Re: [HACKERS] CTE inlining - Mailing list pgsql-hackers

From Andreas Karlsson
Subject Re: [HACKERS] CTE inlining
Date
Msg-id a5908071-fdfd-a0e3-e438-60229aa4a3fd@proxel.se
Whole thread Raw
In response to Re: [HACKERS] CTE inlining  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [HACKERS] CTE inlining
List pgsql-hackers
On 05/03/2017 07:33 PM, Alvaro Herrera wrote:
> 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.
>
>
> 2) unmarked CTEs continue to be an optimization barrier, but we add
> "WITH INLINED" so that they're inlineable.  Some users may wonder about
> it and waste a lot of time trying to figure out which CTEs to add it to.
> They see a benefit in half the queries, which makes them happy, but they
> are angry that they had to waste all that time on the other queries.
>
>
> 3) We don't do anything, because we all agree that GUCs are not
> suitable.  No progress.  No anger, but nobody is happy either.

+1 for option 1. And while I would not like if we had to combine it with 
a backwards compatibility GUC which enables the old behavior to get it 
merged I still personally would prefer that over option 2 and 3.

Andreas



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] How huge does mvtest_huge need to be?