Re: 2nd Level Buffer Cache - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: 2nd Level Buffer Cache
Date
Msg-id 4D8393B1.2080305@agliodbs.com
Whole thread Raw
In response to 2nd Level Buffer Cache  (Radosław Smogura <rsmogura@softperience.eu>)
List pgsql-hackers
Radek,

> 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.

The problem with any "special" buffering of database objects (other than 
maybe the system catalogs) improves one use case at the expense of 
others.  For example, special buffering of indexes would have a negative 
effect on use cases which are primarily seq scans.  Also, how would your 
index buffer work for really huge indexes, like GiST and GIN indexes?

In general, I think that improving the efficiency/scalability of our 
existing buffer system is probably going to bear a lot more fruit than 
adding extra levels of buffering.

That being said, one my argue that the root pages of btree indexes are a 
legitimate special case.   However, it seems like clock-sweep would end 
up keeping those in shared buffers all the time regardless.

--                                   -- Josh Berkus                                     PostgreSQL Experts Inc.
                           http://www.pgexperts.com
 



pgsql-hackers by date:

Previous
From: Devrim GÜNDÜZ
Date:
Subject: Re: 2nd Level Buffer Cache
Next
From: Tom Lane
Date:
Subject: Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)