On Wed, May 15, 2013 at 8:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> I've been thinking for a while that we need some other system for >> managing other kinds of invalidations. For example, suppose we want >> to cache relation sizes in blocks. So we allocate 4kB of shared >> memory, interpreted as an array of 512 8-byte entries. Whenever you >> extend a relation, you hash the relfilenode and take the low-order 9 >> bits of the hash value as an index into the array. You increment that >> value either under a spinlock or perhaps using fetch-and-add where >> available. > > I'm not sure I believe the details of that. > > 1. 4 bytes is not enough to store the exact identity of the table that > the cache entry belongs to, so how do you disambiguate?
You don't. The idea is that it's inexact. When a relation is extended, every backend is forced to recheck the length of every relation whose relfilenode hashes to the same array slot as the one that was actually extended. So if you happen to be repeatedly scanning relation A, and somebody else is repeatedly scanning relation B, you'll *probably* not have to invalidate anything. But if A and B happen to hash to the same slot, then you'll keep getting bogus invalidations. Fortunately, that isn't very expensive. The fast-path locking code uses a similar trick to detect conflicting strong locks, and it works quite well. In that case, as here, you can reduce the collision probability as much as you like by increasing the number of slots, at the cost of increased shared memory usage. > 2. If you don't find an entry for your target rel in the cache, aren't > you still going to have to do an lseek? Don't think of it as a cache. The caching happens inside each backend's relcache; the shared memory structure is just a tool to force those caches to be revalidated when necessary. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers