Re: contrib/pg_stat_statements 1202 - Mailing list pgsql-hackers

From Vladimir Sitnikov
Subject Re: contrib/pg_stat_statements 1202
Date
Msg-id 1d709ecc0812041326t6885813at457a73796076c433@mail.gmail.com
Whole thread Raw
In response to contrib/pg_stat_statements 1202  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: contrib/pg_stat_statements 1202
Re: contrib/pg_stat_statements 1202
List pgsql-hackers

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?

Write-counters are not included because I think they are not so useful.
Never say never. I guess they (or just one counter for accumulated writes) could be useful for monitoring operations that spill to the disk. For instance, PostgreSQL does not show the amount of temp used for the join.



   buffer_gets;        /* # of buffer hits */
   buffer_hits;        /* # of buffer gets */
   buffile_reads;      /* # of buffile reads */
I guess it makes sense expanding "buffile reads" into "buffer file reads" or just "file reads"

Here is an sample output. We'd better to add a linebreak before
the 'actual' section because the line is too wide to display.
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?

 
ResetBufferUsage() is save the current counters in global variables as
baseline and buffer statistics are measured in difference from them
because the counters are used by struct Instrumentation.
That would definitely work well for Instrumentation (it will not notice resetBufferUsage any more), however that will not isolate the guys who do the reset. I am afraid the idea of having api for "reset" is broken and it makes sense removing that function. However it looks like it is out of scope of this patch.

Regards,
Vladimir Sitnikov

pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Simple postgresql.conf wizard
Next
From: "Kevin Grittner"
Date:
Subject: Re: Simple postgresql.conf wizard