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