diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2008-09-09 18:58:09 +0000 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2008-09-09 18:58:09 +0000 |
| commit | ee33b95d9c2ecec170bc517783d7268a4bd0c793 (patch) | |
| tree | 9012453a44799d20b15b2e4dcb1fb5e6784e2a7e /src/backend/utils/cache/ts_cache.c | |
| parent | c06629c72e7e3d435e207c2f80de3aa8a97c1d04 (diff) | |
| download | postgresql-ee33b95d9c2ecec170bc517783d7268a4bd0c793.tar.gz | |
Improve the plan cache invalidation mechanism to make it invalidate plans
when user-defined functions used in a plan are modified. Also invalidate
plans when schemas, operators, or operator classes are modified; but for these
cases we just invalidate everything rather than tracking exact dependencies,
since these types of objects seldom change in a production database.
Tom Lane; loosely based on a patch by Martin Pihlak.
Diffstat (limited to 'src/backend/utils/cache/ts_cache.c')
| -rw-r--r-- | src/backend/utils/cache/ts_cache.c | 15 |
1 files changed, 8 insertions, 7 deletions
diff --git a/src/backend/utils/cache/ts_cache.c b/src/backend/utils/cache/ts_cache.c index 81ff577125..33b415ac6f 100644 --- a/src/backend/utils/cache/ts_cache.c +++ b/src/backend/utils/cache/ts_cache.c @@ -20,7 +20,7 @@ * Copyright (c) 2006-2008, PostgreSQL Global Development Group * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/utils/cache/ts_cache.c,v 1.7 2008/04/12 23:14:21 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/utils/cache/ts_cache.c,v 1.8 2008/09/09 18:58:08 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -79,18 +79,19 @@ static Oid TSCurrentConfigCache = InvalidOid; /* - * We use this catcache callback to detect when a visible change to a TS + * We use this syscache callback to detect when a visible change to a TS * catalog entry has been made, by either our own backend or another one. - * We don't get enough information to know *which* specific catalog row - * changed, so we have to invalidate all related cache entries. Fortunately, - * it seems unlikely that TS configuration changes will occur often enough - * for this to be a performance problem. + * + * In principle we could just flush the specific cache entry that changed, + * but given that TS configuration changes are probably infrequent, it + * doesn't seem worth the trouble to determine that; we just flush all the + * entries of the related hash table. * * We can use the same function for all TS caches by passing the hash * table address as the "arg". */ static void -InvalidateTSCacheCallBack(Datum arg, Oid relid) +InvalidateTSCacheCallBack(Datum arg, int cacheid, ItemPointer tuplePtr) { HTAB *hash = (HTAB *) DatumGetPointer(arg); HASH_SEQ_STATUS status; |
