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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Patch: add timing of buffer I/O requests
Следующее
От: Andres Freund
Дата:
Сообщение: Re: pg_upgrade improvements