Re: Patch: add timing of buffer I/O requests

Jim Nasby <jim@nasby.net>

From: Jim Nasby <jim@nasby.net>
To: Ants Aasma <ants.aasma@eesti.ee>
Cc: Greg Smith <greg@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2012-02-24T22:07:57Z
Lists: pgsql-hackers
On 2/22/12 10:35 AM, Ants Aasma wrote:
> The reason why I didn't add write timings to relation stats is that I
> couldn't figure out what the semantics should be. It could be either
> "time spent waiting for this relations blocks to be written out" or
> "time spent waiting for some other relations blocks to be written out
> to free space for this relations block" or maybe distribute the cost,
> background writes could be included or excluded. Writes usually return
> quickly, unless lots of possibly unrelated writes have dirtied enough
> of OS cache, etc. I figured that what ever choices I made, they
> wouldn't really help anyone diagnose anything. Having global write
> timings in pg_stat_bgwriter might be useful, but I feel that is
> something for another patch.

I know it's not perfect, but I would argue that what users care about most of the time is time taken up in actual backends. So I wouldn't worry about bgwriter. I also wouldn't worry about time spent waiting to find a buffer at this point (see below).

>> >  I still think a full wait timing interface is the right long-term direction
>> >  here.  It's hard to reject this idea when it seems to be working right now
>> >  though, while more comprehensive wait storage is still at least a release
>> >  off.   Opinions welcome, I'm still juggling this around now that I have it
>> >  working again.
> I agree that wait timing interface is the right direction. I have
> thought a bit about it and could share some ideas - maybe I should
> create a wiki page where the general design could be hashed out?

Yes, I think a wiki would be a good place to start. As you showed in your previous question about writes there's a *lot* of places where timing info would be useful to us.
-- 
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net