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

From Andrew Dunstan
Subject Re: [HACKERS] CTE inlining
Date
Msg-id 7c784fd6-36ff-dd30-aad6-6cac3b6292cc@2ndQuadrant.com
Whole thread Raw
In response to Re: [HACKERS] CTE inlining  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: [HACKERS] CTE inlining  (Craig Ringer <craig@2ndquadrant.com>)
Re: [HACKERS] CTE inlining  (David Fetter <david@fetter.org>)
List pgsql-hackers

On 05/01/2017 09:05 AM, Tomas Vondra wrote:
> On 05/01/2017 06:22 AM, Pavel Stehule wrote:
>>
>>
>> 2017-05-01 1:21 GMT+02:00 Andres Freund <andres@anarazel.de
>> <mailto:andres@anarazel.de>>:
>>
>>     On 2017-04-30 07:19:21 +0200, Pavel Stehule wrote:
>>     > why we cannot to introduce GUC option - enable_cteoptfence ?
>>
>>     Doesn't really solve the issue, and we've generally shied away
>> from GUCs
>>     that influence behaviour after a few bad experiences.  What if
>> you want
>>     one CTE inlined, but another one not?
>>
>>
>> It change behave in same sense like enable_nestloop, enable_hashjoin,
>> ... with same limits.
>>
>
> Those (and also the other enable_*) GUCs are a great example why we
> should not use GUCs for tweaking planner behavior, except perhaps for
> the purpose of investigation. It's an extremely blunt tool.
>
> You typically want to affect just a single node in the query plan
> (say, one join), but those options don't allow you to do that. It's
> all or nothing thing.
>
> Even if you're OK with affecting the whole query, it's a separate
> control channel - it's not embedded in the query, the user has to set
> it somehow. So you either set it for the whole session (affecting all
> the other queries that don't really need it), or you set it before
> each query. Which however sucks for a number of reasons, e.g. if you
> have a slow query in the log, how do you know with what GUC values it
> was executed? (You don't, and there's no way to find out.)
>
> Exactly the same issues would affect this new GUC. It would be
> impossible to use multiple CTEs in the query with different fencing
> behavior, and it would be just as difficult to investigate.
>
> So no more planner-affecting GUCs, please, particularly if we expect
> regular users to use them.
>
>


+1

I still see users wanting to use the enable_foo settings in production.

Having had years of telling users that CTEs are an optimization fence it
doesn't seem at all nice for us to turn around and change our mind about
that. I have relied on it in the past and I'm sure I'm very far from
alone in that.

Maybe we could allow a "decorator" that would tell the planner the CTE
could be inlined?
   WITH INLINE mycte AS ( ...)

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Bug in prepared statement cache invalidation?
Next
From: "Joshua D. Drake"
Date:
Subject: Re: [HACKERS] PG 10 release notes