Re: [HACKERS] Protect syscache from bloating with negative cache entries

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Protect syscache from bloating with negative cache entries
Дата
Msg-id 4647.1484315911@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Protect syscache from bloating with negative cache entries  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [HACKERS] Protect syscache from bloating with negative cache entries  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] Too many autovacuum workers spawned during forcedauto-vacuum
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries