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
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 |