Re: explain_regress, explain(MACHINE), and default to explain(BUFFERS) (was: BUFFERS enabled by default in EXPLAIN (ANALYZE))

On Sat, Nov 05, 2022 at 10:43:07AM -0400, Tom Lane wrote:
> Justin Pryzby <pryzby(at)telsasoft(dot)com> 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