On 29.11.2011 02:14, Jim Nasby wrote:
> 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.
Yup, that's right. The wait times are generally much more interesting
than the cached/not cached ratio.
Tomas