From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Vik Fearing <vik(at)postgresfriends(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Default gucs for EXPLAIN |
Date: | 2020-05-27 00:29:24 |
Message-ID: | CAKFQuwbedG7HXhaeTuJ-sCOxmXL36UOkwkxLQDAuPtLn=io8_Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 26, 2020 at 4:53 PM David Rowley <dgrowleyml(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2020-05-27 00:40:19 | Re: Trouble with hashagg spill I/O pattern and costing |
Previous Message | David G. Johnston | 2020-05-27 00:13:30 | Re: Default gucs for EXPLAIN |