public inbox for [email protected]  

help / color / mirror / Atom feed

From: Justin Pryzby <[email protected]>
To: Tom Lane <[email protected]>
Cc: Laurenz Albe <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: Nikolay Samokhvalov <[email protected]>
Cc: [email protected]
Subject: Re: explain_regress, explain(MACHINE), and default to explain(BUFFERS) (was: BUFFERS enabled by default in EXPLAIN (ANALYZE))
Date: Thu, 1 Dec 2022 12:08:56 -0600
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<CAKFQuwbnT_B9i4NFWXX0V=xdcsTi0XTHvm6NVcr8XHi39O_A7w@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On Sat, Nov 05, 2022 at 10:43:07AM -0400, Tom Lane wrote:
> Justin Pryzby <[email protected]> writes:
> > You set the patch to "waiting on author", which indicates that there's
> > no need for further input or review.  But, I think that's precisely
> > what's needed - without input from more people, what could I do to
> > progress the patch ?  I don't think it's reasonable to put 001 first and
> > change thousands (actually, 1338) of regression results.  If nobody
> > wants to discuss 001, then this patch series won't progress.
> 
> Well ...
> 
> 1. 0001 invents a new GUC but provides no documentation for it.
> That certainly isn't committable, and it's discouraging the
> discussion you seek because people have to read the whole patch
> in detail to understand what is being proposed.
> 
> 2. The same complaint for 0004, which labors under the additional

I suggested that the discussion be limited to the early patches (004 is
an optional, possible idea that I had, but it's evidently still causing
confusion).

> 3. I'm not really on board with the entire approach.  Making
> EXPLAIN work significantly differently for developers and test
> critters than it does for everyone else seems likely to promote
> confusion and hide bugs.  I don't think getting rid of the need
> for filter functions in test scripts is worth that.

I'm open to suggestions how else to move towards the goal.

Note that there's a few other things which have vaguely-similar
behavior:

HIDE_TABLEAM=on
HIDE_TOAST_COMPRESSION=on
compute_query_id = regress

Another possibility is to make a new "explain" format, like
| explain(FORMAT REGRESS, ...).

...but I don't see how that's would be less objectionable than what I've
written.

The patch record should probably be closed until someone proposes
another way to implement what's necessary to enable explain(BUFFERS) by
default.

-- 
Justin

view thread (14+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: explain_regress, explain(MACHINE), and default to explain(BUFFERS) (was: BUFFERS enabled by default in EXPLAIN (ANALYZE))
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox