From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Publish checkpoint timing and sync files summary data to pg_stat_bgwriter |
Date: | 2012-04-05 15:51:06 |
Message-ID: | CAMkU=1xV=EmfevMKpheECkr8uFTV42ivvrrD0grYrXCg6E9g-A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 28, 2012 at 7:23 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Although I liked the idea of separating this out, I wasn't thinking we
> should do it as part of this patch. It seems like an independent
> project. At any rate, I strongly agree that counting the number of
> strategy allocations is not really a viable proxy for counting the
> number of backend writes. You can't know how many of those actually
> got dirtied.
I was thinking that it would be part of this patch, but only because
Greg mentioned the view format stabilizing. If it is going to be
frozen, I wanted this in it. But I guess stabilize and fossilize are
different things...
> Since any backend write is necessarily the result of that backend
> trying to allocate a buffer, I think maybe we should just count
> whether the number of times it was trying to allocate a buffer *using
> a BAS* vs. the number of times it was trying to allocate a buffer *not
> using a BAS*. That is, decide whether or not it's a "strategy write"
> not based on whether the buffer came in via a strategy allocation, but
> rather based on whether it's going out as a result of a strategy
> allocation.
Yes, exactly.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-04-05 16:04:32 | Re: pg_upgrade improvements |
Previous Message | Robert Haas | 2012-04-05 15:45:58 | Re: Patch: add timing of buffer I/O requests |