Skip site navigation (1) Skip section navigation (2)

Re: Syscaches should store negative entries, too

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To:
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Syscaches should store negative entries, too
Date: 2002-01-30 19:00:17
Message-ID: 25113.1012417217@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Marc G. FournierDate: 2002-01-30 19:29:57
Subject: PostgreSQL Final Release ... Monday?
Previous:From: Matthew T. O'ConnorDate: 2002-01-30 18:42:14
Subject: Re: [ADMIN] postgresql under Windows is slow

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group