Re: Default gucs for EXPLAIN - Mailing list pgsql-hackers

On Tue, 26 May 2020 at 23:59, Vik Fearing <vik@postgresfriends.org> wrote:
>
> On 5/26/20 1:30 PM, David Rowley wrote:
> > 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.
>
>
> Nah, this argument doesn't hold.  If an app wants something on or off,
> it should say so.  If it doesn't care, then it doesn't care.
>
> Are you saying we should have all new EXPLAIN options off forever into
> the future because apps won't know about the new data?  I guess we
> should also not ever introduce new plan nodes because those won't be
> known either.

I don't think this is a particularly good counter argument.  If we add
a new executor node then that's something that the server will send to
the client.  The client does not need knowledge about which version of
PostreSQL it is connected to. If it receives details about some new
node type in an EXPLAIN then it can be fairly certain that the server
supports that node type.

What we're talking about here is the opposite direction. The client is
sending the command to the server, and the command it'll need to send
is going to have to be specific to the server version.   Now perhaps
all such tools already have good infrastructure to change behaviour
based on version, after all, these tools do also tend to query
catalogue tables from time to time and those change between versions.
Perhaps it would be good to hear from authors of such tools and get
their input.  If they all agree that it's not a problem then that
certainly weakens my argument, but if they don't then perhaps you
should reconsider.

David