Horton

Re: Protect syscache from bloating with negative cache entries

ktm@rice.edu <ktm@rice.edu>

View thread View on postgr.es
From: Kenneth Marshall <ktm@rice.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>, '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>, "andres@anarazel.de" <andres@anarazel.de>, "robertmhaas@gmail.com" <robertmhaas@gmail.com>, "michael.paquier@gmail.com" <michael.paquier@gmail.com>, "david@pgmasters.net" <david@pgmasters.net>, "Jim.Nasby@bluetreble.com" <Jim.Nasby@bluetreble.com>, "craig@2ndquadrant.com" <craig@2ndquadrant.com>
Date: 2019-01-15T18:44:19Z
Lists: pgsql-hackers 
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

Commits

  1. Replace CLOBBER_CACHE_ALWAYS with run-time GUC

  2. Remove the limit on the number of entries allowed in catcaches, and