db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Google SoC: Derby Cache Manager
Date Mon, 05 Jun 2006 21:32:39 GMT
Are you considering any algorithms which would take input ahead of
time on the "value" of the page.  The following kind of information
may be interesting and could be provided with changed interfaces
by the cache caller:
o size of the page (derby currently caches multiple page sizes in
   a single cache and hides this fromthe cache manager).
o page is part of a sequential scan
o page is part of a index scan
o page is root page of btree
o level of page in btree
o page is part of a bulk load which has finished with this page, and 
thus probably should be tossed

scans are interesting in that it may be important to keep small
scans in cache, while very harmful to keep large scans in cache.
One way I have seen to handle this is to keep a "shadow" cache
which tracks more pages than actually fit in cache.  Then on
the first scan don't cache the pages, and then on the second
scan cache them if the shadow cache says it would have helped.

I think most of the btree stuff automatically gets picked up by
reasonable cache algorithms as more important btree pages tend
to be accessed more often, so generally are valued more by all
the algorithms.

Knut Anders Hatlen wrote:
> Gokul Soundararajan <gokul.soundar@gmail.com> writes:
>>Hi all,
>>I'm a Google SoC student working on creating a CacheManager with a
>>better cache replacement algorithm. After talking with my mentor
>>(Oystein Grovlen), I have created a bunch of small prototypes to
>>evaluate different algorithms found in literature.
>>I have run them for a Zipf workload for 0.5 and 0.8 and posted the
>>results on the Derby Wiki.
>>Link: http://wiki.apache.org/db-derby/DerbyLruCacheManager
>>The results show that the 2Q, CAR, and CART algorithms perform better
>>than LRU and Clock.

View raw message