Re: Default gucs for EXPLAIN

Le mar. 26 mai 2020 à 04:27, Stephen Frost <sfrost(at)snowman(dot)net> a écrit :

> Greetings,
>
> * Michael Paquier (michael(at)paquier(dot)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.