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

From David G. Johnston
Subject Re: Default gucs for EXPLAIN
Date
Msg-id CAKFQuwbedG7HXhaeTuJ-sCOxmXL36UOkwkxLQDAuPtLn=io8_Q@mail.gmail.com
Whole thread Raw
In response to Re: Default gucs for EXPLAIN  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On Tue, May 26, 2020 at 4:53 PM David Rowley <dgrowleyml@gmail.com> wrote:
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.

The above is basically how I imagine explain handling software works today - if it sees a specific structure in the output it processes it.  It has zero expectations about whether a feature with a option knob is set to true or false.  And its deals with the one non-boolean option by examining the output text.
 
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.

I don't see how adding these optional GUCs impacts that materially.  If the client provides a custom UI to the user and then writes an explain command itself it will need to possibly understand version differences whether these GUCs exist or not.

To hammer the point home if that client software is memorizing the choices made for the various options and then conditions its output based upon those choices then it should be specifying every one of them explicitly, in which case the GUCs wouldn't matter.  If it is somehow depending upon the existing defaults and user choices to figure out the option values then, yes, the GUCs would be hidden information that may possibly confuse it if, say, a user has a GUC BUFFERS on but didn't make a choice in the client UI which defaulted to FALSE mimicking our default and because the default was chosen didn't output BUFFER off but left the option unspecified and now the buffers appear, which it for some reason isn't expecting and thus blows up.  I could care less about that client and certainly wouldn't let its possible existence hold me back from adding a feature that bare-bones client users who send their own explain queries would find useful.

David J.

pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Default gucs for EXPLAIN
Next
From: Jeff Davis
Date:
Subject: Re: Trouble with hashagg spill I/O pattern and costing