On 05/01/2017 06:22 AM, Pavel Stehule wrote:
2017-05-01 1:21 GMT+02:00 Andres Freund <and...@anarazel.de <mailto:and...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers