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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
