ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp writes:
I think there two independent items here:
[1] Should we add those statistics to pg_stat_statements or not?
[2] Should we add those statistics to EXPLAIN ANALYZE or not?
I wanted to have [1] and proposed it, but it is rejected from
Tom Lane t...@sss.pgh.pa.us writes:
No, I think you misunderstood me entirely. The reason that I rejected
those parts of the patch is that I think the statistics that are
available are wrong/useless. If the bufmgr.c counters were really good
for something they'd have been exposed long since
What did you want done with this patch? It is unlikely we want to see
those counters by default, and we have had little demand for them.
---
Vladimir Sitnikov wrote:
Hi all,
Here is a patch that adds buffer pool
Bruce Momjian br...@momjian.us writes:
What did you want done with this patch? It is unlikely we want to see
those counters by default, and we have had little demand for them.
Here is a patch that adds buffer pool statistics to the explain analyze
output revealing the number of buffer pages
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
What did you want done with this patch? It is unlikely we want to see
those counters by default, and we have had little demand for them.
Here is a patch that adds buffer pool statistics to the explain analyze
output revealing the
Bruce Momjian escribió:
What did you want done with this patch? It is unlikely we want to see
those counters by default, and we have had little demand for them.
If there are two people who need them bad enough to have written a patch
for them, this seems to say that there is a certain demand
On Thu, Jan 8, 2009 at 17:30, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
What did you want done with this patch? It is unlikely we want to see
those counters by default, and we have had little demand for them.
Here is a patch that adds
Alex Hunsaker bada...@gmail.com wrote:
What did you want done with this patch? It is unlikely we want to see
those counters by default, and we have had little demand for them.
This was already rejected in connection with pg_stat_statements, no?
You know, I thought we discussed it
Hi all,
Here is a patch that adds buffer pool statistics to the explain analyze
output revealing the number of buffer pages hit at each and every execution
step.
It uses counters from storage/buffer/bufmgr.c (I believe all that counters
are relevant for investigation of query performance).
Vladimir Sitnikov [EMAIL PROTECTED] wrote:
I've tried to use ReadBufferCount and friends from
storage\buffer\buf_init.c, however it is showing zeroes for some unknown yet
reason. Hope, there is no fundamental problem behind.
I think those vairables are hard to use and have no reliability
for
Hi,
I believe it makes sense adding some more details to explain analyze output
like the number of pages read/written.
This will allow one to understand the workload the query puts on the server
making it easier to tune queries, choose the best indices, etc.
As far as I understand, this patch is
Vladimir Sitnikov [EMAIL PROTECTED] writes:
Hi,
I believe it makes sense adding some more details to explain analyze output
like the number of pages read/written. This will allow one to understand the
workload the query puts on the server making it easier to tune queries,
choose the best
The main problem I ran into was that the instrumentation nodes currently are
nested. That is, all the time for your children counts against you as well.
Is
that what we want for I/O costs?
As for me, I see nothing wrong with such costs model. I think it is good to
know stuff like the whole
13 matches
Mail list logo
