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

From Stephen Frost
Subject Re: Default gucs for EXPLAIN
Date
Msg-id 20200526142515.GE3418@tamriel.snowman.net
Whole thread Raw
In response to Re: Default gucs for EXPLAIN  (Guillaume Lelarge <guillaume@lelarge.info>)
Responses Re: Default gucs for EXPLAIN
List pgsql-hackers
Greetings,

* Guillaume Lelarge (guillaume@lelarge.info) wrote:
> Le mar. 26 mai 2020 à 04:27, Stephen Frost <sfrost@snowman.net> a écrit :
> > 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.

It's only a behaviour change if you enable it.. and the suggestion I
made specifically wouldn't even be a regular 'explain', you'd be using
'\explain' in psql, a new command.

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

The proposal you're commenting on (seemingly mine, anyway) didn't
include adding any new GUCs.

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Trouble with hashagg spill I/O pattern and costing
Next
From: Stephen Frost
Date:
Subject: Re: Default gucs for EXPLAIN