Date: Tue, 7 May 2019 23:23:55 +0200
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
Message-ID: <20190507212355.GQ28936@fetter.org>
References: <20190507073046.GI28936@fetter.org>
 <20190507154147.l32a3erg4mbycj7u@alap3.anarazel.de>
 <20190507163411.GM28936@fetter.org>
 <20190507164430.a7tig676hjzdnyyd@alap3.anarazel.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20190507164430.a7tig676hjzdnyyd@alap3.anarazel.de>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

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