From: David Fetter <david@fetter.org>
To: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: New EXPLAIN option: ALL
Date: Tue, 7 May 2019 23:23:55 +0200
Message-ID: <20190507212355.GQ28936@fetter.org> (raw)
In-Reply-To: <20190507164430.a7tig676hjzdnyyd@alap3.anarazel.de>
References: <20190507073046.GI28936@fetter.org>
<20190507154147.l32a3erg4mbycj7u@alap3.anarazel.de>
<20190507163411.GM28936@fetter.org>
<20190507164430.a7tig676hjzdnyyd@alap3.anarazel.de>
On Tue, May 07, 2019 at 09:44:30AM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-07 18:34:11 +0200, David Fetter wrote:
> > On Tue, May 07, 2019 at 08:41:47AM -0700, Andres Freund wrote:
> > > On 2019-05-07 09:30:47 +0200, David Fetter wrote:
> > > > It can get a little tedious turning on (or off) all the boolean
> > > > options to EXPLAIN, so please find attached a shortcut.
> > >
> > > I'm not convinced this is a good idea - it seems likely that we'll
> > > add conflicting options at some point, and then this will just be a
> > > pain in the neck.
> >
> > I already left out FORMAT for a similar reason, namely that it's not a
> > boolean, so it's not part of flipping on (or off) all the switches.
>
> Which is already somewhat hard to explain.
>
> Imagine if we had CPU_PROFILE = on (which'd be *extremely*
> useful). Would you want that to be switched on automatically? How about
> RECORD_IO_TRACE? How about DISTINCT_BUFFERS which'd be like BUFFERS
> except that we'd track how many different buffers are accessed using HLL
> or such? Would also be extremely useful.
>
>
> > Are you seeing a point in the future where there'd be both mutually
> > exclusive boolean options and no principled reason to choose among
> > them? If so, what might it look like?
>
> Yes. CPU_PROFILE_PERF, CPU_PROFILE_VTUNE. And lots more.
Thanks for clarifying.
Would you agree that there's a problem here as I described as
motivation for people who operate databases?
If so, do you have one or more abbreviations in mind that aren't
called ALL? I realize that Naming Things™ is one of two hard problems
in computer science, but it's still one we have to tackle.
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
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: david@fetter.org, andres@anarazel.de
Subject: Re: New EXPLAIN option: ALL
In-Reply-To: <20190507212355.GQ28936@fetter.org>
* 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