Re: New EXPLAIN option: ALL

From: Andres Freund <andres(at)anarazel(dot)de>
To: David Fetter <david(at)fetter(dot)org>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New EXPLAIN option: ALL
Date: 2019-05-07 16:44:30
Message-ID: 20190507164430.a7tig676hjzdnyyd@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2019-05-07 16:47:59 Re: [PATCH v1] Add a way to supply stdin to TAP tests
Previous Message David Fetter 2019-05-07 16:34:11 Re: New EXPLAIN option: ALL