Re: Protect syscache from bloating with negative cache entries

From: 'Bruce Momjian' <bruce(at)momjian(dot)us>
To: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "alvherre(at)alvh(dot)no-ip(dot)org" <alvherre(at)alvh(dot)no-ip(dot)org>, "michael(dot)paquier(at)gmail(dot)com" <michael(dot)paquier(at)gmail(dot)com>, "david(at)pgmasters(dot)net" <david(at)pgmasters(dot)net>, "craig(at)2ndquadrant(dot)com" <craig(at)2ndquadrant(dot)com>
Subject: Re: Protect syscache from bloating with negative cache entries
Date: 2019-02-21 22:24:34
Message-ID: 20190221222434.cciuwxdtbcc7j2qv@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 19, 2019 at 07:08:14AM +0000, Tsunakawa, Takayuki wrote:
> We all have to manage things within resource constraints. The DBA
> wants to make sure the server doesn't overuse memory to avoid crash
> or slowdown due to swapping. Oracle does it, and another open source
> database, MySQL, does it too. PostgreSQL does it with shared_buffers,
> wal_buffers, and work_mem (within a single session). Then, I thought
> it's natural to do it with catcache/relcache/plancache.

I already addressed these questions in an email from Feb 14:

https://www.postgresql.org/message-id/20190214154955.GB19578@momjian.us

I understand the operational needs of limiting resources in some cases,
but there is also the history of OS's using working set to allocate
things, which didn't work too well:

https://en.wikipedia.org/wiki/Working_set

I think we need to address the most pressing problem of unlimited cache size
bloat and then take a holistic look at all memory allocation. If we
are going to address that in a global way, I don't see the relation
cache as the place to start.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2019-02-21 22:45:11 Re: Vectors instead of lists, specialised qsort(), binary_search(), unique()
Previous Message Robbie Harwood 2019-02-21 22:21:28 Re: [PATCH v20] GSSAPI encryption support