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
