From: Kenneth Marshall <ktm@rice.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>
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: andres@anarazel.de <andres@anarazel.de>
Cc: robertmhaas@gmail.com <robertmhaas@gmail.com>
Cc: michael.paquier@gmail.com <michael.paquier@gmail.com>
Cc: david@pgmasters.net <david@pgmasters.net>
Cc: Jim.Nasby@bluetreble.com <Jim.Nasby@bluetreble.com>
Cc: craig@2ndquadrant.com <craig@2ndquadrant.com>
Subject: Re: Protect syscache from bloating with negative cache entries
Date: Tue, 15 Jan 2019 12:44:19 -0600
Message-ID: <20190115184419.GF22649@aart.rice.edu> (raw)
In-Reply-To: <2365.1547577156@sss.pgh.pa.us>
References: <4E72940DA2BF16479384A86D54D0988A6F1BCB6F@G01JPEXMBKW04>
<20181019.173457.68080786.horiguchi.kyotaro@lab.ntt.co.jp>
<4E72940DA2BF16479384A86D54D0988A6F1F4165@G01JPEXMBKW04>
<20181127.193622.252197705.horiguchi.kyotaro@lab.ntt.co.jp>
<4E72940DA2BF16479384A86D54D0988A6F3D09C1@G01JPEXMBKW04>
<4E72940DA2BF16479384A86D54D0988A6F3D0D5F@G01JPEXMBKW04>
<7925.1547397565@sss.pgh.pa.us>
<0A3221C70F24FB45833433255569204D1FB67733@G01JPEXMBYT05>
<2365.1547577156@sss.pgh.pa.us>
On Tue, Jan 15, 2019 at 01:32:36PM -0500, Tom Lane wrote:
> ...
> > FYI, Oracle provides one parameter, shared_pool_size, that determine the
> > size of a memory area that contains SQL plans and various dictionary
> > objects. Oracle decides how to divide the area among constituents. So
> > it could be possible that one component (e.g. table/index metadata) is
> > short of space, and another (e.g. SQL plans) has free space. Oracle
> > provides a system view to see the free space and hit/miss of each
> > component. If one component suffers from memory shortage, the user
> > increases shared_pool_size. This is similar to what Horiguchi-san is
> > proposing.
>
> Oracle seldom impresses me as having designs we ought to follow.
> They have a well-earned reputation for requiring a lot of expertise to
> operate, which is not the direction this project should be going in.
> In particular, I don't want to "solve" cache size issues by exposing
> a bunch of knobs that most users won't know how to twiddle.
>
> regards, tom lane
+1
Regards,
Ken
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: ktm@rice.edu, tgl@sss.pgh.pa.us, tsunakawa.takay@jp.fujitsu.com, horiguchi.kyotaro@lab.ntt.co.jp, ideriha.takeshi@jp.fujitsu.com, pgsql-hackers@lists.postgresql.org, alvherre@alvh.no-ip.org, andres@anarazel.de, robertmhaas@gmail.com, michael.paquier@gmail.com, david@pgmasters.net, Jim.Nasby@bluetreble.com, craig@2ndquadrant.com
Subject: Re: Protect syscache from bloating with negative cache entries
In-Reply-To: <20190115184419.GF22649@aart.rice.edu>
* 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