Re: Default gucs for EXPLAIN

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Bruce Momjian <bruce(at)momjian(dot)us>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Default gucs for EXPLAIN
Date: 2020-05-26 13:10:41
Message-ID: CAFj8pRBiu=51iE8DeYUuF_yc356e44j4KfNXK0ffnoUMc1Md4w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

út 26. 5. 2020 v 4:27 odesílatel Stephen Frost <sfrost(at)snowman(dot)net> napsal:

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

the partial solution can be custom psql statements. Now, it can be just
workaround

\set explain 'explain (analyze, buffers)'
:explain select * from pg_class ;

and anybody can prepare customized statements how he likes

Regards

Pavel

> Thanks,
>
> Stephen
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2020-05-26 13:21:47 Re: what can go in root.crt ?
Previous Message Jeff Janes 2020-05-26 13:10:40 max_slot_wal_keep_size comment in postgresql.conf