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

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(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net