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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: EXPLAIN's handling of output-a-field-or-not decisions
Дата
Msg-id 20200127012835.pdmfq65s5aqm4xhj@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: EXPLAIN's handling of output-a-field-or-not decisions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2020-01-26 17:53:09 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > 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.

Yea, a GUC could work too. What would it do exactly? Hide COSTS, TIMING,
JIT, unless explicitly turned on in the EXPLAIN? And perhaps also
"redact" a few things that we currently manually have to filter out?
And then we'd leave the implicit JIT to on, to allow users to see where
time is spent?

Or were you thinking of something different entirely?


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

Hm. Would it really be harder? I'd expect that we'd end up writing tests
in master that need additional options to be usable in the back
branches. Seems we'd definitely need to backpatch the GUC?

Greetings,

Andres Freund



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

Предыдущее
От: Mark Dilger
Дата:
Сообщение: Re: making the backend's json parser work in frontend code
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: making the backend's json parser work in frontend code