Re: Patch: add timing of buffer I/O requests
От | Jim Nasby |
---|---|
Тема | Re: Patch: add timing of buffer I/O requests |
Дата | |
Msg-id | 4F480A3D.8030604@nasby.net обсуждение исходный текст |
Ответ на | Re: Patch: add timing of buffer I/O requests (Ants Aasma <ants.aasma@eesti.ee>) |
Список | 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
В списке pgsql-hackers по дате отправления: