Re: Explain Analyze (Rollback off) Suggestion

On Wed, May 27, 2020 at 9:33 PM David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> I'm not seeing enough similarity with the reasons for, and specific behaviors, of those previous GUCs to dismiss this proposal on that basis alone. These are "crap we messed things up" switches that alter a query behind the scenes in ways that a user cannot do through SQL - they simply provide for changing a default that we already allow the user to override per-query. Its akin to "DateStyle" and its pure cosmetic influencing ease-of-use option rather than some changing the fundamental structural meaning of '\n'

Well, I think it's usually worse to have two possible behaviors rather
than one. Like, a lot of people have probably made the mistake of
running EXPLAIN ANALYZE without realizing that it's actually running
the query, and then been surprised or dismayed afterwards. But each
person only has to learn that once. If we had a GUC controlling this
behavior, then you'd have to always be aware of the setting on any
particular system on which you might be thinking of running the
command. Likewise, if you write an application or tool of some sort
that uses EXPLAIN ANALYZE, it has to be aware of the GUC value, or it
won't work as expected on some systems.

This is the general problem with behavior-changing GUCs. I kind of
have mixed feelings about this. On the one hand, it sucks for
operators of individual systems not to be able to customize things so
as to produce the behavior they want. On the other hand, each one you
add makes it harder to write code that will work the same way on every
PostgreSQL system. I don't think the problem would be as bad in this
particular case as in some others that have been proposed, mostly
because EXPLAIN ANALYZE isn't widely-used by applications, so maybe
it's worth considering. But on the whole, I'm inclined to agree with
Tom that it's better not to create too many ways for fundamental
behavior of the system to vary from one installation to another.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company