On Thu, May 16, 2013 at 1:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >>> 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. > > Hmm. Now I see: it's not a cache, it's a Bloom filter.
Yes. > The failure > mode I was thinking of is inapplicable, but there's a different one: > you have to be absolutely positive that *any* operation that extends the > file will update the relevant filter entry. Still, I guess that we're > already assuming that any such op will take the relation's extension > lock, so it should be easy enough to find all the places to fix. I would think so. The main thing that's held me back from actually implementing this is the fact that lseek is so darn cheap on Linux, and I don't have reliable data one way or the other for any other platform. -- 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
