On 04/17/2014 09:38 PM, Stephen Frost wrote:
* Greg Stark (st...@mit.edu) wrote:
On Thu, Apr 17, 2014 at 12:21 PM, Stephen Frost <sfr...@snowman.net> wrote:
Ehhh. No. If it's a hot page that we've been holding in *our* cache
long enough, the kernel will happily evict it as 'cold' from *its*
cache, leading to...
This is a whole nother problem.
It is worrisome that we could be benchmarking the page replacement
algorithm in Postgres and choose a page replacement algorithm that
chooses pages that performs well because it tends to evict pages that
are in the OS cache. And then one day (hopefully not too far off)
we'll fix the double buffering problem and end up with a strange
choice of page replacement algorithm.
That's certainly possible but I don't see the double buffering problem
going away any time particularly soon and, even if it does, it's likely
to either a) mean we're just using the kernel's cache (eg: something w/
mmap, etc), or b) will involve so many other changes that this will end
up getting changed anyway. In any case, while I think we should
document any such cache management system we employ as having this risk,
I don't think we should worry about it terribly much.
Note that if we somehow come up with a page replacement algorithm that
tends to evict pages that are in the OS cache, we have effectively
solved the double buffering problem. When a page is cached in both
caches, evicting it from one of them eliminates the double buffering.
Granted, you might prefer to evict it from the OS cache instead, and
such an algorithm could be bad in other ways. But if a page replacement
algorithm happens avoid double buffering, that's a genuine merit for
that algorithm.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
