2Q implementaion for PostgreSQL buffer replacement.

Started by Yutaka tanidaalmost 23 years ago5 messageshackers
Jump to latest
#1Yutaka tanida
yutaka@nonsensecorner.com

Hi.

I implement 2Q algorithm to PostgreSQL for buffer management , instead
of LRU.
It's known as low overhead and high performance than LRU. If you have
some interests , see following URL.

http://www.vldb.org/conf/1994/P439.PDF

In my test (pgbench -S) , it improves 4% cache hit rate and 2% up
performance comparing from LRU.

Do you have any interest about this patch?

--
Yutaka tanida <yutaka@nonsensecorner.com>
http://www.nonsensecorner.com/

Attachments:

qq_1.patchapplication/octet-stream; name=qq_1.patchDownload+2-0
buf_init.c.diffapplication/octet-stream; name=buf_init.c.diffDownload+23-9
freelist.c.diffapplication/octet-stream; name=freelist.c.diffDownload+151-123
#2Bruce Momjian
bruce@momjian.us
In reply to: Yutaka tanida (#1)
Re: 2Q implementaion for PostgreSQL buffer replacement.

Looks good to me --- we will include it in 7.4.

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------

Yutaka tanida wrote:

Hi.

I implement 2Q algorithm to PostgreSQL for buffer management , instead
of LRU.
It's known as low overhead and high performance than LRU. If you have
some interests , see following URL.

http://www.vldb.org/conf/1994/P439.PDF

In my test (pgbench -S) , it improves 4% cache hit rate and 2% up
performance comparing from LRU.

Do you have any interest about this patch?

--
Yutaka tanida <yutaka@nonsensecorner.com>
http://www.nonsensecorner.com/

[ Attachment, skipping... ]

[ Attachment, skipping... ]

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#3Yutaka tanida
yutaka@nonsensecorner.com
In reply to: Bruce Momjian (#2)
Re: 2Q implementaion for PostgreSQL buffer replacement.

On Mon, 23 Jun 2003 23:49:17 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us> wrote:

Looks good to me --- we will include it in 7.4.

Thanks.But please note it is not completed yet. I must implement more ,
and move configurable parameter to postgresql.conf file.

--
Yutaka tanida <yutaka@nonsensecorner.com>
http://www.nonsensecorner.com/

#4Bruce Momjian
bruce@momjian.us
In reply to: Yutaka tanida (#3)
Re: 2Q implementaion for PostgreSQL buffer replacement.

OK, thanks. I will remove it from the queue, and someone suggested a
different algorithm today:

I was researching on cache replacement strategy as well. 2Q has one
disadvantage see this exellent paper:
http://www.almaden.ibm.com/cs/people/dmodha/#ARC see the paper
"ARC: A Self-Tuning, Low Overhead Replacement Cache" for theory and "One
Up on LRU" for implementation details. ARC requires no tuning and can
switch fast between chaging patterns. Best of all is it is resistant to a
"sequential scan" pattern. and i think it's even easier to implement then
2q :)

---------------------------------------------------------------------------

Yutaka tanida wrote:

On Mon, 23 Jun 2003 23:49:17 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us> wrote:

Looks good to me --- we will include it in 7.4.

Thanks.But please note it is not completed yet. I must implement more ,
and move configurable parameter to postgresql.conf file.

--
Yutaka tanida <yutaka@nonsensecorner.com>
http://www.nonsensecorner.com/

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#5Bruce Momjian
bruce@momjian.us
In reply to: Yutaka tanida (#1)
Re: 2Q implementaion for PostgreSQL buffer replacement.

Patch removed at author's request.

---------------------------------------------------------------------------

Yutaka tanida wrote:

Hi.

I implement 2Q algorithm to PostgreSQL for buffer management , instead
of LRU.
It's known as low overhead and high performance than LRU. If you have
some interests , see following URL.

http://www.vldb.org/conf/1994/P439.PDF

In my test (pgbench -S) , it improves 4% cache hit rate and 2% up
performance comparing from LRU.

Do you have any interest about this patch?

--
Yutaka tanida <yutaka@nonsensecorner.com>
http://www.nonsensecorner.com/

[ Attachment, skipping... ]

[ Attachment, skipping... ]

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073