Re: EXPLAIN's handling of output-a-field-or-not decisions
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2020-01-26T22:53:09Z
Lists: 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
Commits
-
Fix EXPLAIN (SETTINGS) to follow policy about when to print empty fields.
- 3ec20c7091e9 13.0 landed
- bad494380210 12.2 landed
-
Fix some infelicities in EXPLAIN output for parallel query plans.
- 8ebb69f85445 9.6.0 cited