Re: Review of: explain / allow collecting row counts without timing info

From: Noah Misch <noah(at)leadboat(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Review of: explain / allow collecting row counts without timing info
Date: 2012-02-04 00:37:51
Message-ID: 20120204003751.GA24073@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 03, 2012 at 11:12:33AM -0500, Robert Haas wrote:
> After looking at this a bit, I think we can make the interface a bit
> more convenient. I'd like to propose that we call the EXPLAIN option
> "ROWS" rather than "TIMING", and that we provide the row-count
> information if *either* ROWS or ANALYZE is specified.
>
> Then, if you want rows without timing, you can say this:
>
> EXPLAIN (ROWS) query...
>
> Rather than, as in the approach taken by the current patch:
>
> EXPLAIN (ANALYZE, TIMING off) query...
>
> ...which is a little more long-winded.

I favor the originally-submitted syntax. I like having a single option,
ANALYZE, signal whether to actually run the statement. The submitted syntax
also aligns with the fact that would motivate someone to use it: "Timing has
high overhead on my system." or "Timing makes the output unstable."

We have both estimated row counts and actual row counts. It may someday prove
useful to have an invocation that plans the query and shows estimated row
counts, omitting only cost estimates. Having a "ROWS" option that implies
running the query could complicate that effort.

Thanks,
nm

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2012-02-04 02:16:02 Re: some longer, larger pgbench tests with various performance-related patches
Previous Message Daniel Farina 2012-02-04 00:33:39 Re: Should we add crc32 in libpgport?