On 2014-10-12 23:13:27 +1300, David Rowley wrote:
> On Wed, Sep 24, 2014 at 8:02 AM, Christoph Berg <c...@df7cb.de> wrote:
>
> > Re: Tom Lane 2014-09-23 <15155.1411493...@sss.pgh.pa.us>
> > > Robert Haas <robertmh...@gmail.com> writes:
> > > > On Sat, Sep 20, 2014 at 4:13 PM, Christoph Berg <c...@df7cb.de> wrote:
> > > >> Can we have "EXPLAIN (timing off)" in 9.4+ hide the "Planning time"
> > > >> line? That would even be backwards compatible with 9.x where it would
> > > >> be a no-op.
> > >
> > > > I don't think that'll work becuase:
> > >
> > > > /* check that timing is used with EXPLAIN ANALYZE */
> > > > if (es.timing && !es.analyze)
> > > > ereport(ERROR,
> > > >
> > (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> > > > errmsg("EXPLAIN option TIMING
> > > > requires ANALYZE")));
> > >
> > > It looks to me like that would complain about EXPLAIN (TIMING ON),
> > > not the case Christoph is suggesting. What he proposes seems a bit
> > > odd and non-orthogonal, but we could make the code do it if we wanted.
> >
> > I don't think this warrants a new flag, and TIMING OFF seems to be the
> > right naming for it. (In fact it was the first I tried, and I was
> > cursing quite a bit over the lack of configurability until I realized
> > that COSTS OFF disabled the planning time display as well.) It might
> > be a bit odd, but it's easy to remember.
> >
> >
>
> I'm pretty interested in seeing something change around here.
> The patch I'm working on at the moment (INNER JOIN removals) implements
> "skipping" of joins at execution time rather than planning time. Currently
> I'm working on the regression test for this and it's not all that easy due
> to the execution time appearing in the results.
>
> An explain analyze output from master with the patch can look something
> like:
>
> explain (analyze, costs off, timing off)
> select a.* from a inner join b on a.b_id = b.id inner join c on b.c_id =
> c.id;
> QUERY PLAN
> ---------------------------------------------------
> Hash Join (actual rows=1 loops=1)
> Hash Cond: (b.c_id = c.id)
> -> Hash Join (actual rows=1 loops=1)
> Hash Cond: (a.b_id = b.id)
> -> Seq Scan on a (actual rows=1 loops=1)
> -> Hash (never executed)
> -> Seq Scan on b (never executed)
> -> Hash (never executed)
> -> Seq Scan on c (never executed)
> Execution time: 0.092 ms
> (10 rows)
So you're now the third person reporting problems here. Let's remove
'execution time' for COSTS off.
I personally would even say that we should backpatch that to make
backpatches involving regression tests less painful.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
