Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Dec 19, 2017 at 3:31 AM, Kyotaro HORIGUCHI
> <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
>> I see three kinds of syscache entries.
>>
>> A. An entry for an actually existing object.
>> B. An entry for an object which once existed but no longer.
>> C. An entry for a just non-existent objects.
> I'm not convinced that it's useful to divide things up this way.
Actually, I don't believe that case B exists at all; such an entry
should get blown away by syscache invalidation when we commit the
DROP command. If one were to stick around, we'd risk false positive
lookups later.
> I guess I still don't see why B is different. If somebody sits there
> and runs queries against non-existent table names at top speed, maybe
> they'll query the same non-existent table entries more than once, in
> which case keeping the negative entries for the non-existent table
> names around until they stop doing it may improve performance.
FWIW, my recollection is that the reason for negative cache entries
is that there are some very common patterns where we probe for object
names (not just table names, either) that aren't there, typically as
a side effect of walking through the search_path looking for a match
to an unqualified object name. Those cache entries aren't going to
get any less useful than the positive entry for the ultimately-found
object. So from a lifespan point of view I'm not very sure that it's
worth distinguishing cases A and C.
It's conceivable that we could rewrite all the lookup algorithms
so that they didn't require negative cache entries to have good
performance ... but I doubt that that's easy to do.
regards, tom lane