Re: 2nd Level Buffer Cache
Kevin Grittner <kevin.grittner@wicourts.gov>
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "PG Hackers" <pgsql-hackers@postgresql.org>, Rados*aw Smogura <rsmogura@softperience.eu>
Date: 2011-03-17T21:02:18Z
Lists: pgsql-hackers
Rados*aw Smogura<rsmogura@softperience.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