On 2014-10-13 11:46:16 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Sun, Oct 12, 2014 at 11:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> I have no great objection to making both COSTS OFF and TIMING OFF suppress
> >> the "planning time" output, if that's the consensus. I would object to
> >> taking away that behavior of COSTS OFF, because of the implications for
> >> back-patching EXPLAIN queries in regression tests.
> >>
> >> Another possibility, which would introduce less non-orthogonality into
> >> the switch design, is to remove the connection to COSTS OFF but say that
> >> planning time is only printed when execution time is also printed (ie,
> >> only in EXPLAIN ANALYZE). This seems to me that it would not be removing
> >> much functionality, because if you just did a plain EXPLAIN then you can
> >> take the client-side runtime (psql \timing) as a close-enough estimate
> >> of planning time.
>
> > That'd be fine with me. Making it controlled by COSTS and/or TIMING
> > would be OK with me, too. But let's do *something*.
>
> After sleeping on it, the second idea seems cleaner to me: it removes one
> wart rather than adding a second one. If there are no objections, I'll
> go make it so.
Well. Unless I miss something it doesn't resolve the problem that
started this thread. Namely that it's currently impossible to write
regression using EXPLAIN (ANALYZE, TIMING OFF. COSTS OFF). Which is
worthwhile because it allows to tests some behaviour that's only visible
in actually executed plans (like seing that a subtree wasn't executed).
I think we should try to find a solution that solves the problem for
execution/plan time problem at the same time...
We could just make TIMING a tristate variable (really-off, off, on). Not
very satisfying given that we have to preserve the current behaviour
with OFF :(.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services