aboutsummaryrefslogtreecommitdiff
path: root/src/include
diff options
context:
space:
mode:
Diffstat (limited to 'src/include')
-rw-r--r--src/include/storage/sinval.h32
-rw-r--r--src/include/utils/catcache.h25
-rw-r--r--src/include/utils/inval.h6
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 */