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
