Tom Lane 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 (and we'd prob
ITAGAKI Takahiro 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 8.4.
> However, the reason is
"Alex Hunsaker" 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 i
On Thu, Jan 8, 2009 at 17:30, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian 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 statist
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 dema
Tom Lane wrote:
> Bruce Momjian 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 numb
Bruce Momjian 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 hit at ea
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 sta
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).
He
"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 reliabi
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
"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 th
12 matches
Mail list logo
