Re: 2nd Level Buffer Cache

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: 2nd Level Buffer Cache
Date: 2011-03-18 17:17:37
Message-ID: 4D8393B1.2080305@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Erik Rijkers 2011-03-18 17:19:49 pg_ctl restart - behaviour based on wrong instance
Previous Message Simon Riggs 2011-03-18 17:15:25 Re: Sync Rep and shutdown Re: Sync Rep v19