Skip site navigation (1) Skip section navigation (2)

Re: 2nd Level Buffer Cache

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "PG Hackers" <pgsql-hackers(at)postgresql(dot)org>, Rados*aw Smogura <rsmogura(at)softperience(dot)eu>
Subject: Re: 2nd Level Buffer Cache
Date: 2011-03-17 21:02:18
Message-ID: 4D82308A020000250003BA50@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Rados*aw Smogura<rsmogura(at)softperience(dot)eu> wrote:
 
> I have implemented initial concept of 2nd level cache. Idea is to
> keep some segments of shared memory for special buffers (e.g.
> indices) to prevent overwrite those by other operations. I added
> those functionality to nbtree index scan.
> 
> I tested this with doing index scan, seq read, drop system
> buffers, do index scan and in few places I saw performance
> improvements, but actually, I'm not sure if this was just "random"
> or intended improvement.
 
I've often wondered about this.  In a database I developed back in
the '80s it was clearly a win to have a special cache for index
entries and other special pages closer to the database than the
general cache.  A couple things have changed since the '80s (I mean,
besides my waistline and hair color), and PostgreSQL has many
differences from that other database, so I haven't been sure it
would help as much, but I have wondered.
 
I can't really look at this for a couple weeks, but I'm definitely
interested.  I suggest that you add this to the next CommitFest as a
WIP patch, under the Performance category.
 
https://commitfest.postgresql.org/action/commitfest_view/open
 
> There is few places to optimize code as well, and patch need many
> work, but may you see it and give opinions?
 
For something like this it makes perfect sense to show "proof of
concept" before trying to cover everything.
 
-Kevin

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2011-03-17 21:22:10
Subject: FK constraints "NOT VALID" by default?
Previous:From: Jesper KroghDate: 2011-03-17 20:02:58
Subject: Re: really lazy vacuums?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group