Re: Publish checkpoint timing and sync files summary data to pg_stat_bgwriter
От | Robert Haas |
---|---|
Тема | Re: Publish checkpoint timing and sync files summary data to pg_stat_bgwriter |
Дата | |
Msg-id | CA+TgmoZynSOH8T+CAtYbqKqdQKAdpRX1axTL=kiBGf3ksP9T3w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Publish checkpoint timing and sync files summary data to pg_stat_bgwriter (Peter Geoghegan <peter@2ndquadrant.com>) |
Ответы |
Re: Publish checkpoint timing and sync files summary data
to pg_stat_bgwriter
|
Список | pgsql-hackers |
On Sat, Mar 31, 2012 at 5:34 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote: >> 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. > > I'm not quite sure I understand what you mean here. Are you suggesting > that I produce a revision that bumps beside FlushBuffer() in > BufferAlloc(), as a dirty page is evicted/written, while breaking the > figure out into != BAS_NORMAL and == BAS_NORMAL figures? Would both > figures be presented as separate columns within pg_stat_bgwriter? Well, for 9.2, I am asking that you rip all that stuff out of the patch altogether so we can focus on the stuff that was in the original patch. For 9.3, yes, that's what I'm suggesting, although I'll defer to you, Jeff, and others on whether it's a *good* suggestion. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: