Re: EXPLAIN's handling of output-a-field-or-not decisions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: EXPLAIN's handling of output-a-field-or-not decisions
Дата
Msg-id 18494.1580079189@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: EXPLAIN's handling of output-a-field-or-not decisions  (Andres Freund <andres@anarazel.de>)
Ответы Re: EXPLAIN's handling of output-a-field-or-not decisions
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2020-01-26 16:54:58 -0500, Tom Lane wrote:
>> ... how are you going to square that desire with not breaking the
>> regression tests?

> Well, that's how we arrived at turning off JIT information when COSTS
> OFF, because that's already something all the EXPLAINs in the regression
> tests have to do. I do not want to regress from the current state, with
> regard to both regression tests, and seeing at least a top-line time in
> the normal EXPLAIN ANALYZE cases.

Right, but that's still just a hack.

> I've previously wondered about adding a REGRESS option to EXPLAIN would
> not actually be a good one, so we can move the magic into that, rather
> than options that are also otherwise relevant.

I'd be inclined to think about a GUC actually.
force_parallel_mode = regress is sort of precedent for that,
and we do already have the infrastructure needed to force a
database-level GUC setting for regression databases.

I can see some advantages to making it an explicit EXPLAIN option
instead --- but unless we wanted to back-patch it, it'd be a real
pain in the rear for back-patching regression test cases.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Parallel leader process info in EXPLAIN
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Duplicate Workers entries in some EXPLAIN plans