Re: New EXPLAIN option: ALL

From: David Fetter <david(at)fetter(dot)org>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New EXPLAIN option: ALL
Date: 2019-05-07 22:39:01
Message-ID: 20190507223900.GR28936@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 07, 2019 at 06:12:56PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> >
> > One idea that comes to mind is that VERBOSE could be redefined as
> > some sort of package of primitive options, including all of the
> > "additional information" options, with the ability to turn
> > individual ones off again if you wanted. So for example (VERBOSE,
> > BUFFERS OFF) would give you everything except buffer stats. We'd
> > need a separate flag/flags to control what VERBOSE originally did,
> > but that doesn't bother me --- it's an opportunity for more
> > clarity of definition, anyway.
>
> 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.

So basically, every format but text gets the full treatment for
(essentially) the functionality I wrapped up in ALL? That makes a lot
of sense.

> > 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 and people will potentially propose patches to do that,
> which we will then almost certainly spend hours arguing about with the
> result being that we don't actually remove it.

Excellent point.

> I'm all in favor of adding an alias for analyze called 'execute', as
> that makes a lot more sense and then updating our documentation to
> use it, with 'analyze is accepted as an alias' as a footnote.

How about making ANALYZE a backward-compatibility feature in the sense
of replacing examples, docs, etc., with EXECUTE? If most of our users
are in the future, this makes those same users's better without
qualification, and helps some positive fraction of our current users.

On a slightly related topic, we haven't, to date, made any promises
about what EXPLAIN will put out, but as we make more machine-readable
versions, we should at least think about its schema and versioning
of same.

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-05-07 22:45:36 Re: Heap lock levels for REINDEX INDEX CONCURRENTLY not quite right?
Previous Message Heikki Linnakangas 2019-05-07 22:31:55 Re: Failure in contrib test _int on loach