Re: Syscaches should store negative entries, too

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