Re: Heap truncation without AccessExclusiveLock (9.4)

Robert Haas <robertmhaas(at)gmail(dot)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?

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?

Having said that, the idea of specialized caches in shared memory seems
plenty reasonable to me.

One thing that's bothering me about Heikki's proposal is that it's not
clear that it's a *cache*; that is, I don't see the fallback logic to
use when there's no entry for a relation for lack of room.

regards, tom lane