On Fri, May 12, 2017 at 3:39 PM, Bruce Momjian <br...@momjian.us> wrote:
> On Tue, May  9, 2017 at 05:14:19PM -0400, Tom Lane wrote:
>> Ilya Shkuratov <motr.i...@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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to