| From: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(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-03-31 21:34:33 |
| Message-ID: | CAEYLb_W4JW+2wg0ViecWJSUy3dQAuH=WZMkuFX4=ORbqxkk=fw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 28 March 2012 15:23, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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.
Sure.
> 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?
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-03-31 21:44:05 | Re: [HACKERS] Re: pg_dump incredibly slow dumping a single schema from a large db |
| Previous Message | Robert Haas | 2012-03-31 21:14:38 | Re: measuring lwlock-related latency spikes |