I wrote:
> AFAICS there's no logical difficulty in doing this: we simply make
> a catcache entry that contains the probed-for key values but is
> marked "no one home at this address". If a probe hits one of these
> things, it can return NULL without a trip to the catalog. If someone
> later comes along and creates a tuple that matches the key value,
> the negative-result cache entry will be invalidated in the usual way
> (this should work because insertion and update are treated identically
> in the caches).
That last claim is false, unfortunately. Shared cache invalidation
treats inserts differently from updates and deletes (see the comments
at the top of src/backend/utils/cache/inval.c).
To make negative cache entries work correctly, we'd have to issue
cross-backend SI messages for inserts into the system catalogs, not
only for updates and deletes. This would mean more SI traffic than
there is now. I think it'd still be a win, but the case for negative
cache entries isn't quite as airtight as I thought. There could be
scenarios where the extra SI traffic outweighs the savings from avoiding
failing catalog searches.
Comments anyone?
regards, tom lane
