Re: Publish checkpoint timing and sync files summary data to pg_stat_bgwriter
От | Jeff Janes |
---|---|
Тема | Re: Publish checkpoint timing and sync files summary data to pg_stat_bgwriter |
Дата | |
Msg-id | CAMkU=1xV=EmfevMKpheECkr8uFTV42ivvrrD0grYrXCg6E9g-A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Publish checkpoint timing and sync files summary data to pg_stat_bgwriter (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Wed, Mar 28, 2012 at 7:23 AM, Robert Haas <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления: