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-22 22:07:24 |
Message-ID: | CAEYLb_U1V0xHB2Tkz27F5Gq6Fdm0KzGEy2KePz9DQ-KRG=mMjA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 23 January 2012 02:08, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Jan 21, 2012 at 6:32 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> I'm finding the backend_writes column pretty unfortunate. The only
>> use I know of for it is to determine if the bgwriter is lagging
>> behind. Yet it doesn't serve even this purpose because it lumps
>> together the backend writes due to lagging background writes, and the
>> backend writes "by design" due to the use buffer access strategy
>> during bulk inserts.
>
> +1 for separating those.
I decided to have a go myself. Attached patch breaks out strategy
allocations in pg_stat_bgwriter, but not strategy writes. My thinking
is that this may serve to approximate non-BAS_NORMAL writes, with the
considerable advantage of not requiring that I work backwards to
figure out strategy from some block when backend-local syncing (yes,
syncing, not writing) a buffer to work out which strategy object
references the buffer. The bookkeeping that that would likely entail
seems to make it infeasible.
Incidentally, it seems Postgres doesn't currently record backend
writes when the buffer doesn't go on to be sync'd. That seems
problematic to me, or at the very least a misrepresentation, since
temporary tables will be written out by the backend for example. Not
sure if it's worth fixing, though I've added a comment to that effect
at the site of where backend_writes is bumped.
I have corrected the md.c bug. This previously would have prevented
the sync_files (number of relation segments synced) value from being
valid in non-log_checkpoints configurations.
I'm not currently confident that the strategy_alloc filed is a very
useful proxy for a strategy_backend_writes field. I think that rather
than bumping the strategy allocation count analogously to the way the
overall count is bumped (within StrategyGetBuffer()), I should have
bumped earlier within BufferAlloc() so that it'd count if the buffer
was requested with non-BAS_NORMAL strategy but was found in
shared_buffers (so control never got as far as StrategyGetBuffer() ).
That might make the value more closely line-up to the would-be value
of a strategy_backend_writes column. What do you think?
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
Attachment | Content-Type | Size |
---|---|---|
publish-sync-stats-v3.patch | text/x-patch | 29.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2012-03-22 23:03:45 | Re: checkpoint patches |
Previous Message | Tom Lane | 2012-03-22 22:07:16 | Re: Speed dblink using alternate libpq tuple storage |