Re: really lazy vacuums?
От | Greg Stark |
---|---|
Тема | Re: really lazy vacuums? |
Дата | |
Msg-id | AANLkTin4E3MF9yutjPzCMDUE_5x5fA7rkwfMUU6a2BGJ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: really lazy vacuums? (Jim Nasby <jim@nasby.net>) |
Ответы |
Re: really lazy vacuums?
|
Список | pgsql-hackers |
On Mon, Mar 21, 2011 at 6:08 PM, Jim Nasby <jim@nasby.net> wrote: > Has anyone looked at the overhead of measuring how long IO requests to the kernel take? If we did that not only could weget an idea of what our IO workload looked like, we could also figure out whether a block came out of cache or not. Thatinformation could potentially be useful to the planner, but even if the database couldn't use that knowledge itself itwould be a damn useful statistic to have... IMHO, far more useful than our current hit rate statistics. > I've done this -- actually better, I used mincore to actually check whether the block was in cache before issuing the read -- but it turns out you can't get what you're looking for this way. It turns out when you do this you see one block being read from disk followed by n blocks that all appear to be cache hits. Because they've been prefetched by the kernel. What you end up with is actually something like the number of iops which is also an interesting measure but not really what you were looking for. My getrusage patch, which I should still dig out though it's rather too late to be committing now unless someone tells me otherwise, would tell you how much i/o a plan node actually did. But you won't know which blocks did the i/o since I was only tracking totals for the plan node. That's probably what you're looking for here. -- greg
В списке pgsql-hackers по дате отправления: