Re: Page replacement algorithm in buffer cache - Mailing list pgsql-hackers

From Ants Aasma
Subject Re: Page replacement algorithm in buffer cache
Date
Msg-id CA+CSw_se74iDCLswBfF7_Rd1542nhyw-YSmQ+OqDwEzu0rZkSw@mail.gmail.com
Whole thread Raw
In response to Re: Page replacement algorithm in buffer cache  (Atri Sharma <atri.jiit@gmail.com>)
Responses Re: Page replacement algorithm in buffer cache  (Atri Sharma <atri.jiit@gmail.com>)
Re: Page replacement algorithm in buffer cache  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Page replacement algorithm in buffer cache  (Greg Smith <greg@2ndQuadrant.com>)
List pgsql-hackers
On Mar 22, 2013 12:46 PM, "Atri Sharma" <atri.jiit@gmail.com> wrote:

> This is the one I think would work out best, add an age factor as to
> the time duration which an entry has spent in the cache along with its
> usage count.

You might want to check out the LIRS cache replacement algorithm [1].
That algorithm tries to estimate least frequently used instead of
least recently used. Mysql uses it for their buffer replacement
policy. There is also a clock sweep based approximation called
CLOCK-Pro. Papers describing and evaluating both are available on the
net. The evaluations in the papers showed significantly better
performance for both of those compared to regular clock sweep or even
ARC.

However, I think the main issue isn't finding new algorithms that are
better in some specific circumstances. The hard part is figuring out
whether their performance is better in general. My idea was to create
a patch to capture page pinning traffic from PostgreSQL (maybe stream
out into a per backend file), run it with some production workloads
and use that to generate testing workloads for the cache replacement
policies. Haven't gotten round to actually doing that though.

[1] http://en.wikipedia.org/wiki/LIRS_caching_algorithm

Regards,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Should commit_delay be PGC_SIGHUP?
Next
From: Peter Geoghegan
Date:
Subject: Re: Should commit_delay be PGC_SIGHUP?