From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>
Cc: David Fetter <david@fetter.org>
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: New EXPLAIN option: ALL
Date: Tue, 7 May 2019 18:51:48 -0400
Message-ID: <20190507225148.GP6197@tamriel.snowman.net> (raw)
In-Reply-To: <5221.1557267912@sss.pgh.pa.us>
References: <20190507073046.GI28936@fetter.org>
<20190507154147.l32a3erg4mbycj7u@alap3.anarazel.de>
<20190507163411.GM28936@fetter.org>
<20190507164430.a7tig676hjzdnyyd@alap3.anarazel.de>
<20190507212355.GQ28936@fetter.org>
<20190507215449.3a4yb5kkoloq7yyw@alap3.anarazel.de>
<4638.1557266803@sss.pgh.pa.us>
<20190507221255.GO6197@tamriel.snowman.net>
<5221.1557267912@sss.pgh.pa.us>
Greetings,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > I'm generally in favor of doing something like what Tom is suggesting
> > with VERBOSE, but I also feel like it should be the default for formats
> > like JSON. If you're asking for the output in JSON, then we really
> > should include everything that a flag like VERBOSE would contain because
> > you're pretty clearly planning to copy/paste that output into something
> > else to read it anyway.
>
> Meh --- I don't especially care for non-orthogonal behaviors like that.
> If you wanted JSON but *not* all of the additional info, how would you
> specify that? (The implementation I had in mind would make VERBOSE OFF
> more or less a no-op, so that wouldn't get you there.)
You'd do it the same way you proposed for verbose- eg: BUFFERS OFF, et
al, but, really, the point here is that what you're doing with the JSON
result is fundamentally different- you're going to paste it into some
other tool and it should be that tool's job to manage the visualization
of it and what's included or not in what you see. Passing the
information about what should be seen in the json-based EXPLAIN viewer
by way of omitting things from the JSON output strikes me as downright
odd, and doesn't give that other tool the ability to show that data if
the users ends up wanting it without rerunning the query.
> >> I do feel that it's a good idea to keep ANALYZE separate. "Execute
> >> the query or not" is a mighty fundamental thing. I've never liked
> >> that name for the option though --- maybe we could deprecate it
> >> in favor of EXECUTE?
>
> > Let's not fool ourselves by saying we'd 'deprecate' it because that
> > implies, at least to me, that there's some intention of later on
> > removing it
>
> True, the odds of ever actually removing it are small :-(. I meant
> mostly changing all of our docs to use the other spelling, except
> for some footnote. Maybe we could call ANALYZE a "legacy spelling"
> of EXECUTE.
Sure, that'd be fine too.
Thanks,
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, tgl@sss.pgh.pa.us, andres@anarazel.de, david@fetter.org
Subject: Re: New EXPLAIN option: ALL
In-Reply-To: <20190507225148.GP6197@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox