From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Craig Ringer <craig@2ndquadrant.com>
Cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Protect syscache from bloating with negative cache entries
Date: Tue, 20 Dec 2016 15:10:21 -0500
Message-ID: <23492.1482264621@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+TgmoaMPbN5vvH33zLK7MR+PiCYWPvTHmSSrDab4vurLOXS-Q@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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Dec 20, 2016 at 10:09 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I don't understand why we'd make that a system-wide behavior at all,
>> rather than expecting each process to manage its own cache.
> Individual backends don't have a really great way to do time-based
> stuff, do they? I mean, yes, there is enable_timeout() and friends,
> but I think that requires quite a bit of bookkeeping.
If I thought that "every ten minutes" was an ideal way to manage this,
I might worry about that, but it doesn't really sound promising at all.
Every so many queries would likely work better, or better yet make it
self-adaptive depending on how much is in the local syscache.
The bigger picture here though is that we used to have limits on syscache
size, and we got rid of them (commit 8b9bc234a, see also
https://www.postgresql.org/message-id/flat/5141.1150327541%40sss.pgh.pa.us)
not only because of the problem you mentioned about performance falling
off a cliff once the working-set size exceeded the arbitrary limit, but
also because enforcing the limit added significant overhead --- and did so
whether or not you got any benefit from it, ie even if the limit is never
reached. Maybe the present patch avoids imposing a pile of overhead in
situations where no pruning is needed, but it doesn't really look very
promising from that angle in a quick once-over.
BTW, I don't see the point of the second patch at all? Surely, if
an object is deleted or updated, we already have code that flushes
related catcache entries. Otherwise the caches would deliver wrong
data.
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, craig@2ndquadrant.com, horiguchi.kyotaro@lab.ntt.co.jp
Subject: Re: Protect syscache from bloating with negative cache entries
In-Reply-To: <23492.1482264621@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox