On 1 May 2017 at 21:05, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > 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.
Definitely agree. You can't use them to affect only a portion of a query. In fact there's no way to automatically scope them to one query at all. They're also very big hammers, and as we introduce new types of plan nodes they won't offer comprehensive control without being amended. They're a tool of last resort for dealing with problems. > 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. Yeah, I think a GUC is a non-starter. If we want fence behaviour, we should require people to declare their desire for fence behaviour, rather than treating it as a sort of hint-as-a-bug that we grandfather in because we're so desperate not to admit we have hints. Before forming a strong view on this, I strongly everyone stick your head outside the postgresql.org lists for a while. In my experience even regular postgres users I see pop up on places like Stack Overflow tend to react to this behaviour with "WTF?!" and wonder why we haven't fixed this limitation yet, viewing it as a bug not a feature. The same logic being applied here should've prevented us from ever introducing: * inlining of SQL functions * inlining of views * inlining of subqueries ... but somehow, this one is different. We're not even removing functionality. You can still use the OFFSET 0 hack. If you need a nonzero offset that's fine, because we don't inline over OFFSET anyway. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
