Subject: Re: Protect syscache from bloating with negative cache entries
To: 'Bruce Momjian' <bruce@momjian.us>,
 "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Cc: "andres@anarazel.de" <andres@anarazel.de>,
 Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
 Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>,
 "Ideriha, Takeshi" <ideriha.takeshi@jp.fujitsu.com>,
 "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
 "alvherre@alvh.no-ip.org" <alvherre@alvh.no-ip.org>,
 "michael.paquier@gmail.com" <michael.paquier@gmail.com>,
 "david@pgmasters.net" <david@pgmasters.net>,
 "craig@2ndquadrant.com" <craig@2ndquadrant.com>
References: 
 <CA+TgmoY_2MYoLm_qyYPJ3xDMzTVe+Er33F=gXkXxpiHHfgxUDA@mail.gmail.com>
 <20190119010941.6ruftewah7t3k3yk@alap3.anarazel.de>
 <20190121205624.GB1060@momjian.us>
 <0d3806bf-5087-a75f-3592-ee1d508a79db@2ndquadrant.com>
 <B326B25F2E3A4EEABE8D8363D4E37828@tunaPC>
 <883b2580-027e-4cb4-fb21-679c14fdb50a@2ndquadrant.com>
 <0A3221C70F24FB45833433255569204D1FB9723F@G01JPEXMBYT05>
 <9ebe0ac4-b59e-6397-0586-4e7125de7d5b@2ndquadrant.com>
 <20190213202402.GA6933@momjian.us>
 <0A3221C70F24FB45833433255569204D1FB98603@G01JPEXMBYT05>
 <20190214154955.GB19578@momjian.us>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Message-ID: <95bd95f4-761c-78fd-e8eb-ca56b5f94c1f@2ndquadrant.com>
Date: Fri, 15 Feb 2019 17:05:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <20190214154955.GB19578@momjian.us>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 2/14/19 4:49 PM, 'Bruce Momjian' wrote:
> On Thu, Feb 14, 2019 at 01:31:49AM +0000, Tsunakawa, Takayuki wrote:
>> From: Bruce Momjian [mailto:bruce@momjian.us]
>>>> That being said, having a "minimal size" threshold before starting
>>>> with the time-based eviction may be a good idea.
>>>
>>> Agreed.  I see the minimal size as a way to keep the systems tables
>>> in cache, which we know we will need for the next query.
>>
>> Isn't it the maximum size, not minimal size?  Maximum size allows
>> to keep desired amount of system tables in memory as well as to
>> control memory consumption to avoid out-of-memory errors (OS crash!).
>> I'm wondering why people want to take a different approach to
>> catcatch, which is unlike other PostgreSQL memory e.g. shared_buffers,
>> temp_buffers, SLRU buffers, work_mem, and other DBMSs.
> 
> Well, that is an _excellent_ question, and one I had to think about.
> 

I think we're talking about two different concepts here:

1) minimal size - We don't do any extra eviction at all, until we reach
this cache size. So we don't get any extra overhead from it. If a system
does not have issues.

2) maximal size - We ensure the cache size is below this threshold. If
there's more data, we evict enough entries to get below it.

My proposal is essentially to do just (1), so the cache can grow very
large if needed but then it shrinks again after a while.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services