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

From Merlin Moncure
Subject Re: [HACKERS] CTE inlining
Date
Msg-id CAHyXU0yeMHBajnJr475U3fPPTihehST0MpotFRD8BoE9hNNENQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] CTE inlining  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Fri, May 12, 2017 at 3:39 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Tue, May  9, 2017 at 05:14:19PM -0400, Tom Lane wrote:
>> Ilya Shkuratov <motr.ilya@ya.ru> writes:
>> > Ok, it seems that most people in discussion are agree that removing optimization
>> > fence is a right thing to do.
>> > Nonetheless I still hoping to discuss the algorithm and its implementation.
>>
>> Yeah, so far we've mainly discussed whether to do that and how to control
>> it, not what the actual results would be.
>
> To summarize, it seems we have two options if we want to add fence
> control to CTEs:
>
> 1.  add INLINE to disable the CTE fence
> 2.  add MATERIALIZE to enable the CTE fence
>
> or some other keywords.  I think most people prefer #2 because:
>
> *  most users writing queries prefer #2

Yeah, I think there was rough consensus on this point.    I think it's
fair to assume that most (or at least a majority) of queries will
benefit from inlining, people would want to opt out of, rather than
opt in to, generally good optimization strategies.   This will hit
some in people today, but this is not a backwards compatibility issue
since performance is generally not really fairly described as
compatibility criteria.  If this feature drops we ought to warn people
in the release notes though.

merlin



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] WITH clause in CREATE STATISTICS
Next
From: Tom Lane
Date:
Subject: [HACKERS] About forced dependencies on catversion.h