|From:||Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, <robertmhaas(at)gmail(dot)com>, <craig(at)2ndquadrant(dot)com>, <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Protect syscache from bloating with negative cache entries|
|Views:||Raw Message | Whole Thread | Download mbox|
On 1/22/17 4:41 PM, Jim Nasby wrote:
> On 1/21/17 8:54 PM, Tom Lane wrote:
>> Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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
> 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
|Next Message||Tom Lane||2017-01-22 22:53:20||Re: Assignment of valid collation for SET operations on queries with UNKNOWN types.|
|Previous Message||Jim Nasby||2017-01-22 22:41:18||Re: Protect syscache from bloating with negative cache entries|