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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
