On 1/22/17 4:41 PM, Jim Nasby wrote:
On 1/21/17 8:54 PM, Tom Lane wrote:
Jim Nasby <jim.na...@bluetreble.com> writes:
The other (possibly naive) question I have is how useful negative
entries really are? Will Postgres regularly incur negative lookups, or
will these only happen due to user activity?
It varies depending on the particular syscache, but in at least some
of them, negative cache entries are critical for performance.
See for example RelnameGetRelid(), which basically does a RELNAMENSP
cache lookup for each schema down the search path until it finds a
match.
Ahh, I hadn't considered that. So one idea would be to only track
negative entries on caches where we know they're actually useful. That
might make the performance hit of some of the other ideas more
tolerable. Presumably you're much less likely to pollute the namespace
cache than some of the others.
Ok, after reading the code I see I only partly understood what you were
saying. In any case, it might still be useful to do some testing with
CATCACHE_STATS defined to see if there's caches that don't accumulate a
lot of negative entries.
Attached is a patch that tries to document some of this.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)
diff --git a/src/include/utils/catcache.h b/src/include/utils/catcache.h
index 253c7b53ed..d718d82d80 100644
--- a/src/include/utils/catcache.h
+++ b/src/include/utils/catcache.h
@@ -101,7 +101,12 @@ typedef struct catctup
*
* 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
+ * avoiding catalog searches is concerned. In particular, caching
negative
+ * entries is critical for performance of some caches. For example,
current
+ * code will produce a negative RELNAMENSP entry for every un-qualified
+ * table looking with the default search_path that puts the pg_catalog
+ * schema first. This effect can be obverved by defining CATCACHE_STATS
and
+ * observing the log at backend exit. Management of positive and
* negative entries is identical.
*/
int refcount; /* number of active
references */
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
