Re: Review of: explain / allow collecting row counts without timing info - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Review of: explain / allow collecting row counts without timing info
Date
Msg-id 20120204003751.GA24073@tornado.leadboat.com
Whole thread Raw
In response to Re: Review of: explain / allow collecting row counts without timing info  (Robert Haas <robertmhaas@gmail.com>)
List 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


pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: ecpglib use PQconnectdbParams
Next
From: "Kevin Grittner"
Date:
Subject: Re: some longer, larger pgbench tests with various performance-related patches