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
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? |