Re: [HACKERS] Protect syscache from bloating with negative cache entries - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Protect syscache from bloating with negative cache entries
Date
Msg-id 4647.1484315911@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Protect syscache from bloating with negative cache entries  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] Protect syscache from bloating with negative cache entries  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
> Have there been ever discussions about having catcache entries in a
> shared memory area? This does not sound much performance-wise, I am
> just wondering about the concept and I cannot find references to such
> discussions.

I'm sure it's been discussed.  Offhand I remember the following issues:

* A shared cache would create locking and contention overhead.

* A shared cache would have a very hard size limit, at least if it's
in SysV-style shared memory (perhaps DSM would let us relax that).

* Transactions that are doing DDL have a requirement for the catcache
to reflect changes that they've made locally but not yet committed,
so said changes mustn't be visible globally.

You could possibly get around the third point with a local catcache that's
searched before the shared one, but tuning that to be performant sounds
like a mess.  Also, I'm not sure how such a structure could cope with
uncommitted deletions: delete A -> remove A from local catcache, but not
the shared one -> search for A in local catcache -> not found -> search
for A in shared catcache -> found -> oops.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Too many autovacuum workers spawned during forcedauto-vacuum
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries