Re: ARC patent

From: Neil Conway <neilc(at)samurai(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ARC patent
Date: 2005-01-18 22:33:49
Message-ID: 1106087629.22946.157.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2005-01-17 at 15:11 -0500, Andrew Dunstan wrote:
> There's a very recent paper at
> http://carmen.cs.uiuc.edu/~zchen9/paper/TPDS-final.ps on an alternative
> to ARC which claims superior performance ...

>From a quick glance, this doesn't look applicable. The authors are
discussing buffer replacement strategies for a multi-level cache
hierarchy (e.g. they would call the DBMS buffer cache "L1", and the
kernel I/O cache "L2" -- note that despite the terminology, this has
little in common with L1/L2 caches in processors). They don't really
address caching for the L1-only case -- they're concerned with proposing
algorithms to manage the L2 cache (with or without explicit knowledge
about the content of the L1 cache).

A few years ago Tom implemented the LRU-K replacement policy[1], but
AFAIK the performance results from that weren't very positive (since the
implementation of LRU-K requires a heap and is therefore logarithmic
rather than constant time, that makes sense). The 2Q algorithm looks
like it might be worth investigating[2].

-Neil

[1] http://citeseer.ist.psu.edu/16869.html
[2] http://citeseer.ist.psu.edu/63909.html

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sailesh Krishnamurthy 2005-01-18 22:42:32 Re: Much Ado About COUNT(*)
Previous Message Reini Urban 2005-01-18 22:30:09 Re: Some things I like to pick from the TODO list ...