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 j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
