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.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services