From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Bruce Momjian <bruce@momjian.us>
To: Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>
Cc: andres@anarazel.de <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: Ideriha, Takeshi <ideriha.takeshi@jp.fujitsu.com>
Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Cc: alvherre@alvh.no-ip.org <alvherre@alvh.no-ip.org>
Cc: michael.paquier@gmail.com <michael.paquier@gmail.com>
Cc: david@pgmasters.net <david@pgmasters.net>
Cc: craig@2ndquadrant.com <craig@2ndquadrant.com>
Subject: Re: Protect syscache from bloating with negative cache entries
Date: Fri, 15 Feb 2019 17:05:00 +0100
Message-ID: <95bd95f4-761c-78fd-e8eb-ca56b5f94c1f@2ndquadrant.com> (raw)
In-Reply-To: <20190214154955.GB19578@momjian.us>
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>
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
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: tomas.vondra@2ndquadrant.com, bruce@momjian.us, tsunakawa.takay@jp.fujitsu.com, andres@anarazel.de, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, horiguchi.kyotaro@lab.ntt.co.jp, ideriha.takeshi@jp.fujitsu.com, pgsql-hackers@lists.postgresql.org, alvherre@alvh.no-ip.org, michael.paquier@gmail.com, david@pgmasters.net, craig@2ndquadrant.com
Subject: Re: Protect syscache from bloating with negative cache entries
In-Reply-To: <95bd95f4-761c-78fd-e8eb-ca56b5f94c1f@2ndquadrant.com>
* 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