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

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: Review of: explain / allow collecting row counts without timing info
Дата
Msg-id 20120204003751.GA24073@tornado.leadboat.com
обсуждение исходный текст
Ответ на Re: Review of: explain / allow collecting row counts without timing info  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Meskes
Дата:
Сообщение: Re: ecpglib use PQconnectdbParams
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: some longer, larger pgbench tests with various performance-related patches