diff options
Diffstat (limited to 'src/include')
-rw-r--r-- | src/include/storage/sinval.h | 32 | ||||
-rw-r--r-- | src/include/utils/catcache.h | 25 | ||||
-rw-r--r-- | src/include/utils/inval.h | 6 |
3 files changed, 44 insertions, 19 deletions
diff --git a/src/include/storage/sinval.h b/src/include/storage/sinval.h index af88e066e2e..e679910e253 100644 --- a/src/include/storage/sinval.h +++ b/src/include/storage/sinval.h @@ -7,7 +7,7 @@ * Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * - * $Id: sinval.h,v 1.25 2001/11/05 17:46:35 momjian Exp $ + * $Id: sinval.h,v 1.26 2002/03/03 17:47:56 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -28,22 +28,32 @@ * are available to identify other inval message types. * * Shared-inval events are initially driven by detecting tuple inserts, - * updates and deletions in system catalogs (see RelationInvalidateHeapTuple - * and RelationMark4RollbackHeapTuple). Note that some system catalogs have - * multiple caches on them (with different indexes). On detecting a tuple - * invalidation in such a catalog, a separate catcache inval message must be - * generated for each of its caches. The catcache inval message carries the - * hash index for the target tuple, so that the catcache only needs to search - * one hash chain not all its chains. Of course this assumes that all the - * backends are using identical hashing code, but that should be OK. + * updates and deletions in system catalogs (see CacheInvalidateHeapTuple). + * An update generates two inval events, one for the old tuple and one for + * the new --- this is needed to get rid of both positive entries for the + * old tuple, and negative cache entries associated with the new tuple's + * cache key. (This could perhaps be optimized down to one event when the + * cache key is not changing, but for now we don't bother to try.) Note that + * the inval events themselves don't actually say whether the tuple is being + * inserted or deleted. + * + * Note that some system catalogs have multiple caches on them (with different + * indexes). On detecting a tuple invalidation in such a catalog, separate + * catcache inval messages must be generated for each of its caches. The + * catcache inval messages carry the hash value for the target tuple, so + * that the catcache only needs to search one hash chain not all its chains, + * and so that negative cache entries can be recognized with good accuracy. + * (Of course this assumes that all the backends are using identical hashing + * code, but that should be OK.) */ typedef struct { + /* note: field layout chosen with an eye to alignment concerns */ int16 id; /* cache ID --- must be first */ - uint16 hashIndex; /* hashchain index within this catcache */ - Oid dbId; /* database ID, or 0 if a shared relation */ ItemPointerData tuplePtr; /* tuple identifier in cached relation */ + Oid dbId; /* database ID, or 0 if a shared relation */ + uint32 hashValue; /* hash value of key for this catcache */ } SharedInvalCatcacheMsg; #define SHAREDINVALRELCACHE_ID (-1) diff --git a/src/include/utils/catcache.h b/src/include/utils/catcache.h index 6ad0d74851c..cf820e37b8f 100644 --- a/src/include/utils/catcache.h +++ b/src/include/utils/catcache.h @@ -13,7 +13,7 @@ * Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * - * $Id: catcache.h,v 1.38 2002/02/19 20:11:19 tgl Exp $ + * $Id: catcache.h,v 1.39 2002/03/03 17:47:56 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -35,20 +35,28 @@ typedef struct catcache struct catcache *cc_next; /* link to next catcache */ char *cc_relname; /* name of relation the tuples come from */ char *cc_indname; /* name of index matching cache keys */ - int cc_reloidattr; /* AttrNumber of relation OID, or 0 */ + Oid cc_reloid; /* OID of relation the tuples come from */ bool cc_relisshared; /* is relation shared? */ TupleDesc cc_tupdesc; /* tuple descriptor (copied from reldesc) */ + int cc_reloidattr; /* AttrNumber of relation OID attr, or 0 */ int cc_ntup; /* # of tuples currently in this cache */ int cc_size; /* # of hash buckets in this cache */ int cc_nkeys; /* number of keys (1..4) */ int cc_key[4]; /* AttrNumber of each key */ PGFunction cc_hashfunc[4]; /* hash function to use for each key */ ScanKeyData cc_skey[4]; /* precomputed key info for heap scans */ + bool cc_isname[4]; /* flag key columns that are NAMEs */ #ifdef CATCACHE_STATS long cc_searches; /* total # searches against this cache */ long cc_hits; /* # of matches against existing entry */ + long cc_neg_hits; /* # of matches against negative entry */ long cc_newloads; /* # of successful loads of new entry */ - /* cc_searches - (cc_hits + cc_newloads) is # of failed searches */ + /* + * cc_searches - (cc_hits + cc_neg_hits + cc_newloads) is number of + * failed searches, each of which will result in loading a negative entry + */ + long cc_invals; /* # of entries invalidated from cache */ + long cc_discards; /* # of entries discarded due to overflow */ #endif Dllist cc_bucket[1]; /* hash buckets --- VARIABLE LENGTH ARRAY */ } CatCache; /* VARIABLE LENGTH STRUCT */ @@ -68,11 +76,18 @@ typedef struct catctup * A tuple marked "dead" must not be returned by subsequent searches. * However, it won't be physically deleted from the cache until its * refcount goes to zero. + * + * A negative cache entry is an assertion that there is no tuple + * matching a particular key. This is just as useful as a normal entry + * so far as avoiding catalog searches is concerned. Management of + * positive and negative entries is identical. */ Dlelem lrulist_elem; /* list member of global LRU list */ Dlelem cache_elem; /* list member of per-bucket list */ int refcount; /* number of active references */ bool dead; /* dead but not yet removed? */ + bool negative; /* negative cache entry? */ + uint32 hash_value; /* hash value for this tuple's keys */ HeapTupleData tuple; /* tuple management header */ } CatCTup; @@ -104,10 +119,10 @@ extern void ReleaseCatCache(HeapTuple tuple); extern void ResetCatalogCaches(void); extern void CatalogCacheFlushRelation(Oid relId); -extern void CatalogCacheIdInvalidate(int cacheId, Index hashIndex, +extern void CatalogCacheIdInvalidate(int cacheId, uint32 hashValue, ItemPointer pointer); extern void PrepareToInvalidateCacheTuple(Relation relation, HeapTuple tuple, - void (*function) (int, Index, ItemPointer, Oid)); + void (*function) (int, uint32, ItemPointer, Oid)); #endif /* CATCACHE_H */ diff --git a/src/include/utils/inval.h b/src/include/utils/inval.h index 25fb73d570e..d2286ed54ef 100644 --- a/src/include/utils/inval.h +++ b/src/include/utils/inval.h @@ -7,7 +7,7 @@ * Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * - * $Id: inval.h,v 1.23 2001/11/05 17:46:36 momjian Exp $ + * $Id: inval.h,v 1.24 2002/03/03 17:47:56 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -23,8 +23,8 @@ extern void AtEOXactInvalidationMessages(bool isCommit); extern void CommandEndInvalidationMessages(bool isCommit); -extern void RelationInvalidateHeapTuple(Relation relation, HeapTuple tuple); +extern void CacheInvalidateHeapTuple(Relation relation, HeapTuple tuple); -extern void RelationMark4RollbackHeapTuple(Relation relation, HeapTuple tuple); +extern void CacheInvalidateRelcache(Oid relationId); #endif /* INVAL_H */ |