Re: contrib/pg_stat_statements 1202

Поиск
Список
Период
Сортировка
От ITAGAKI Takahiro
Тема Re: contrib/pg_stat_statements 1202
Дата
Msg-id 20081209154601.881B.52131E4D@oss.ntt.co.jp
обсуждение исходный текст
Ответ на Re: contrib/pg_stat_statements 1202  ("Vladimir Sitnikov" <sitnikov.vladimir@gmail.com>)
Ответы Re: contrib/pg_stat_statements 1202  ("Vladimir Sitnikov" <sitnikov.vladimir@gmail.com>)
Re: contrib/pg_stat_statements 1202  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: contrib/pg_stat_statements 1202  ("Robert Haas" <robertmhaas@gmail.com>)
Список pgsql-hackers
"Vladimir Sitnikov" <sitnikov.vladimir@gmail.com> wrote:

> > 2. EXPLAIN ANALYZE VERBOSE shows buffer statistics in 'actual' section.
> >
> I do not get the point of "VERBOSE".
> As far as I understand, explain analyze (without verbose) will anyway add
> overhead for calculation of "gets/hits/cpu". Why discard that information in
> "non verbose" mode? Just to make the investigation more complex?

I thought that output of new counters are too wide and it brakes
compatibility of EXPLAIN ANALYZE. On the other hand, we don't have to
think of compatibility in EXPLAIN ANALYZE VERBOSE because it is newly
added in 8.4. However, overheads should be avoided. We could have
two kinds of instrumentations, time-only or all-stats.

Another idea is to have buffer and cpu counters not in Instrumentation
but in QueryDesc (i.e, only one per query). A new field for the counter
will be initialized in pg_stat_statements module. EXPLAIN ANALYZE could
also use the field but the result is printed only the end of query plan,
as the follows. We can avoid too-wide-line problem with the approach.

=# EXPLAIN ANALYZE SELECT ...;       QUERY PLAN
---------------------------...Total runtime: 24.273 msCPU usage: user=20.2 sys=2.4               # Buffer usage:
gets=100reads=10 writes=20  # added linesTempfile i/o: reads=50 writes=50           # 
 
(10 rows)


> I wish there was a way to get the results of explain into some table. I wish
> it was the default output "format". That would make life of pgAdmin easier,
> and improve readability even in psql. Do not you think there is something
> wrong with having "cost=... rows=... loops=..." in each and every row?

I absolutely agree that XML-explain and TABLE-expalin are useful,
but they are independent features from pg_stat_statements. So I'd
like to discuss them in separated threads (and it will come in 8.5).

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center




В списке pgsql-hackers по дате отправления:

Предыдущее
От: ITAGAKI Takahiro
Дата:
Сообщение: Re: contrib/pg_stat_statements 1202
Следующее
От: "Vladimir Sitnikov"
Дата:
Сообщение: Re: contrib/pg_stat_statements 1202