Re: Default gucs for EXPLAIN - Mailing list pgsql-hackers

From Guillaume Lelarge
Subject Re: Default gucs for EXPLAIN
Date
Msg-id CAECtzeXuH58e=sQQd+MN09bxQXgHCCcooT5NO+sk=eDkyPWmUQ@mail.gmail.com
Whole thread Raw
In response to Re: Default gucs for EXPLAIN  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Default gucs for EXPLAIN
List pgsql-hackers
Le mar. 26 mai 2020 à 04:27, Stephen Frost <sfrost@snowman.net> a écrit :
Greetings,

* Michael Paquier (michael@paquier.xyz) wrote:
> On Mon, May 25, 2020 at 09:36:50PM -0400, Bruce Momjian wrote:
> > I am not excited about this new feature.  Why do it only for EXPLAIN?

Would probably help to understand what your thinking is here regarding
how it could be done for everything...?  In particular, what else are
you thinking it'd be sensible for?

> > That is a log of GUCs.  I can see this becoming a feature creep
> > disaster.

I'd only view it as a feature creep disaster if we end up extending it
to things that don't make any sense..  I don't see any particular reason
why we'd have to do that though.  On the other hand, if there's a clean
way to do it for everything, that'd be pretty neat.

> FWIW, Neither am I.  This would create an extra maintenance cost, and
> I would not want such stuff to spread to other commands either, say
> CLUSTER, VACUUM, REINDEX, etc.  And note that it is always possible to
> do that with a small extension using the utility hook and some
> pre-loaded user-settable GUCs.

The suggestion to "go write C code that will be loaded via a utility
hook" is really entirely inappropriate here.

This strikes me as a pretty reasonable 'creature comfort' kind of idea.
Inventing GUCs to handle it is maybe not the best approach, but we
haven't really got anything better right at hand- psql can't parse
general SQL, today, and hasn't got it's own idea of "how to run
explain".  On the other hand, I could easily see a similar feature
being included in pgAdmin4 where running explain is clicking on a button
instead of typing 'explain'.

To that end- what if this was done client-side with '\explain' or
similar?  Basically, it'd work like \watch or \g but we'd have options
under pset like "explain_analyze t/f" and such.  I feel like that'd also
largely address the concerns about how this might 'feature creep' to
other commands- because those other commands don't work with a query
buffer, so it wouldn't really make sense for them.

As for the concerns wrt explain UPDATE or explain DETELE actually
running the query, that's what transactions are for, and if you don't
feel comfortable using transactions or using these options- then don't.


This means you'll always have to check if the new GUCs are set up in a way it will actually execute the query or to open a transaction for the same reason. This is a huge behaviour change where people might lose data.

I really don't like this proposal (the new GUCs).


--
Guillaume.

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: what can go in root.crt ?
Next
From: Amit Kapila
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions