Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UJ2Yj-0004W8-FZ for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Mar 2013 14:03:05 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UJ2Yi-0002tP-AE for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Mar 2013 14:03:04 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UJ2YR-0002ew-5A for pgsql-hackers@postgresql.org; Fri, 22 Mar 2013 14:02:47 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UJ2YO-0006dG-G1 for pgsql-hackers@postgresql.org; Fri, 22 Mar 2013 14:02:46 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id r2ME2eNe003986; Fri, 22 Mar 2013 10:02:40 -0400 (EDT) From: Tom Lane To: Ants Aasma cc: Atri Sharma , Amit Kapila , PostgreSQL-development Subject: Re: Page replacement algorithm in buffer cache In-reply-to: References: <514bf302.84d5440a.43f2.ffffe411SMTPIN_ADDED_BROKEN@mx.google.com> <08BBC126-D375-4743-B9A6-D1320D05D5C7@gmail.com> <514c3395.487a420a.28d1.764eSMTPIN_ADDED_BROKEN@mx.google.com> Comments: In-reply-to Ants Aasma message dated "Fri, 22 Mar 2013 14:45:58 +0200" Date: Fri, 22 Mar 2013 10:02:39 -0400 Message-ID: <3985.1363960959@sss.pgh.pa.us> X-Pg-Spam-Score: -4.4 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Ants Aasma writes: > 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. I seem to recall that CLOCK-Pro, or something named similarly to that, was one of the alternatives discussed when we went over to the current clock-sweep approach. And we definitely looked at ARC. It might be worth checking the archives from back then to see what's already been considered. > 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. Yeah. You can prove almost anything with the right set of test cases :-( regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers