From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP: explain analyze with 'rows' but not timing |
Date: | 2011-12-23 13:57:12 |
Message-ID: | CA+TgmoYxJRza1uR6dC8+Fp3idPQ-9fnP__LuEp6juf=go-G0FA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2011/12/22 Tomas Vondra <tv(at)fuzzy(dot)cz>:
> The gettimeofday() calls are not exactly cheap in some cases, so why to
> pay that price when all you need is the number of rows?
Fair point.
> The patch attached does this:
>
> 1) adds INSTRUMENT_ROWS, a new InstrumentOption
>
> - counts rows without timing (no gettimeofday() callse)
> - if you want timing info, use INSTRUMENT_TIMER
>
> 2) adds new option "TIMING" to EXPLAIN, i.e.
>
> EXPLAIN (ANALYZE ON, TIMING ON) SELECT ...
>
> 3) adds auto_explain.log_rows_only (false by default)
>
> - if you set this to 'true', then the instrumentation will just
> count rows, without calling gettimeofday()
This seems like an unnecessarily confusing interface, because you've
named the auto_explain option differently from the EXPLAIN option and
given it (almost) the opposite sense: timing=off means the same thing
as log_rows_only=on.
I think the EXPLAIN (TIMING) option is good the way you have it, but
then just have auto_explain.log_timing, with a default value of on.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2011-12-23 14:45:40 | Re: WIP: explain analyze with 'rows' but not timing |
Previous Message | Robert Haas | 2011-12-23 13:42:51 | Re: patch: bytea_agg |