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 по дате отправления: