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
somekind of IO; it doesn't *really* care about whether it was cached. So in that context, we don't really care if SSDs
arefast enough that they look like cache, because that means they're performing (essentially) the same as cache.
--
Jim C. Nasby, Database Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net