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

From: Jim Nasby <jim(at)nasby(dot)net>
To: Tomas Vondra <tv(at)fuzzy(dot)cz>
Cc: "Greg Stark" <stark(at)mit(dot)edu>, "Greg Smith" <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch: add timing of buffer I/O requests
Date: 2011-11-29 01:14:34
Message-ID: 12FEA84E-3B26-4A55-A6A3-214CDBDB9189@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Nov 28, 2011, at 9:29 AM, Tomas Vondra wrote:
>>> I recall a patch similar to this one was submitted by Greg Stark some
>> time ago. It used the info for different reasons--to try and figure out
>> whether reads were cached or not--but I believe it withered rather than
>> being implemented mainly because it ran into the same fundamental
>> roadblocks here. My memory could be wrong here, there were also concerns
>> about what the data would be used for.
>
> The difficulty when distinguishing whether the reads were cached or not is
> the price we pay for using filesystem cache instead of managing our own.
> Not sure if this can be solved just by measuring the latency - with
> spinners it's quite easy, the differences are rather huge (and it's not
> difficult to derive that even from pgbench log). But with SSDs, multiple
> tablespaces on different storage, etc. it gets much harder.

True, but every use case for this information I can think of ultimately only cares about how long it took to perform some kind of IO; it doesn't *really* care about whether it was cached. So in that context, we don't really care if SSDs are fast enough that they look like cache, because that means they're performing (essentially) the same as cache.
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2011-11-29 01:17:48 Re: Patch: add timing of buffer I/O requests
Previous Message Bruce Momjian 2011-11-29 01:11:09 Re: strange nbtree corruption report