On Tue, 26 May 2020 at 13:36, Bruce Momjian <bruce@momjian.us> wrote:
>
> On Sat, May 23, 2020 at 06:16:25PM +0000, Nikolay Samokhvalov wrote:
> > This is a very good improvement! Using information about buffers is my favorite
> > way to optimize queries.
> >
> > Not having BUFFERS enabled by default means that in most cases, when asking for
> > help, people send execution plans without buffers info.
> >
> > And it's simply in on event to type "(ANALYZE, BUFFERS)" all the time.
> >
> > So I strongly support this change, thank you, Vik.
>
> I am not excited about this new feature.
I'm against adding GUCs to control what EXPLAIN does by default.
A few current GUCs come to mind which gives external control to a
command's behaviour are:
standard_conforming_strings
backslash_quote
bytea_output
It's pretty difficult for application authors to write code that will
just work due to these GUCs. We end up with GUCs like
escape_string_warning to try and help application authors find areas
which may be problematic.
It's not an easy thing to search for in the archives, but we've
rejected GUCs that have proposed new ways which can break applications
in this way. For example [1]. You can see some arguments against that
in [2].
Now, there are certainly far fewer applications out there that will
execute an EXPLAIN, but the number is still above zero. I imagine the
authors of those applications might get upset if we create something
outside of the command that controls what the command does. Perhaps
the idea here is not quite as bad as that as applications could still
override the options by mentioning each EXPLAIN option in the command
they send to the server. However, we're not done adding new options
yet, so by doing this we'd be pretty much insisting that applications
that use EXPLAIN know about all EXPLAIN options for the server version
they're connected to. That seems like a big demand given that we've
been careful to still support the old
EXPLAIN syntax after we added the new way to specify the options in parenthesis.
[1] https://www.postgresql.org/message-id/flat/ACF85C502E55A143AB9F4ECFE960660A17282D@mailserver2.local.mstarlabs.com
[2] https://www.postgresql.org/message-id/17880.1482648516%40sss.pgh.pa.us
David