From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael.paquier@gmail.com>
cc: Robert Haas <robertmhaas@gmail.com>, Craig Ringer <craig@2ndquadrant.com>,
        Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Protect syscache from bloating with negative cache entries
In-reply-to: 
 <CAB7nPqQABjAGDzTREuHOgJS3iHY6nVZ+Z2x1cL1JLKBLMpzXTg@mail.gmail.com>
References: <20161219.201505.11562604.horiguchi.kyotaro@lab.ntt.co.jp>
 <CA+Tgmob_ksTOgmbXhno+k5XXPOK+-JYYLoU3MpXuutP4bH7gzA@mail.gmail.com>
 <CAMsr+YHziSok-AM=krEQ+HaRQzst4+M1+2WGYqZw_i6w9vVBvA@mail.gmail.com>
 <30868.1482246558@sss.pgh.pa.us>
 <CA+TgmoaMPbN5vvH33zLK7MR+PiCYWPvTHmSSrDab4vurLOXS-Q@mail.gmail.com>
 <23492.1482264621@sss.pgh.pa.us>
 <CAB7nPqQABjAGDzTREuHOgJS3iHY6nVZ+Z2x1cL1JLKBLMpzXTg@mail.gmail.com>
Comments: In-reply-to Michael Paquier <michael.paquier@gmail.com>
	message dated "Fri, 13 Jan 2017 16:59:26 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4646.1484315911.1@sss.pgh.pa.us>
Date: Fri, 13 Jan 2017 08:58:31 -0500
Message-ID: <4647.1484315911@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers