pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Bruce Momjian <bruce@momjian.us>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: tsunakawa.takay@jp.fujitsu.com
Cc: GavinFlower@archidevsys.co.nz
Cc: robertmhaas@gmail.com
Cc: tgl@sss.pgh.pa.us
Cc: ideriha.takeshi@jp.fujitsu.com
Cc: pgsql-hackers@lists.postgresql.org
Cc: alvherre@alvh.no-ip.org
Cc: andres@anarazel.de
Cc: michael.paquier@gmail.com
Cc: david@pgmasters.net
Cc: Jim.Nasby@bluetreble.com
Cc: craig@2ndquadrant.com
Subject: Re: Protect syscache from bloating with negative cache entries
Date: Thu, 24 Jan 2019 09:47:32 -0500
Message-ID: <20190124144732.GD8334@momjian.us> (raw)
In-Reply-To: <20190124.183924.13894464.horiguchi.kyotaro@lab.ntt.co.jp>
References: <20190121.172255.226467552.horiguchi.kyotaro@lab.ntt.co.jp>
	<20190123.173502.237450969.horiguchi.kyotaro@lab.ntt.co.jp>
	<20190123232145.GA8334@momjian.us>
	<20190124.183924.13894464.horiguchi.kyotaro@lab.ntt.co.jp>

On Thu, Jan 24, 2019 at 06:39:24PM +0900, Kyotaro HORIGUCHI wrote:
> > Second, when would you use syscache_memory_target != 0? 
> 
> It is a suggestion upthread, we sometimes want to keep some known
> amount of caches despite that expration should be activated.
> 
> > If you had
> > syscache_prune_min_age really fast, e.g. 10 seconds?  What is the
> > use-case for this? You have a query that touches 10k objects, and then
> > the connection stays active but doesn't touch many of those 10k objects,
> > and you want it cleaned up in seconds instead of minutes?  (I can't see
> > why you would not clean up all unreferenced objects after _minutes_ of
> > disuse, but removing them after seconds of disuse seems undesirable.)
> > What are the odds you would retain the entires you want with a fast
> > target?
> 
> Do you asking the reason for the unit? It's just because it won't
> be so large even in seconds, to the utmost 3600 seconds.  Even
> though I don't think such a short dutaion setting is meaningful
> in the real world, either I don't think we need to inhibit
> that. (Actually it is useful for testing:p) Another reason is

We have gone from ignoring the cache bloat problem to designing an API
that even we don't know what value they provide, and if we don't know,
we can be sure our users will not know.  Every GUC has a cost, even if
it is not used.

I suggest you go with just syscache_prune_min_age, get that into PG 12,
and we can then reevaluate what we need.  If you want to hard-code a
minimum cache size where no pruning will happen, maybe based on the system
catalogs or typical load, that is fine.

> that GUC_UNIT_MIN doesn't seem so common that it is used only by
> two variables, log_rotation_age and old_snapshot_threshold.
> 
> > What is the value of being able to change a specific backend's stat
> > interval?  I don't remember any other setting having this ability.
> 
> As mentioned upthread, it takes significant time to take
> statistics so I believe no one is willing to turn it on at all
> times.  As the result it should be useless because it cannot be
> turned on on an active backend when it actually gets bloat. So I
> wanted to provide a remote switching feture.
> 
> I also thought that there's some other features that is useful if
> it could be turned on remotely so the remote GUC feature but it
> was too complex...

Well, I am thinking if we want to do something like this, we should do
it for all GUCs, not just for this one, so I suggest we not do this now
either.

-- 
  Bruce Momjian  <bruce@momjian.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 +




view thread (272+ messages)  latest in thread

Message-ID: <20190124144732.GD8334@momjian.us>
Permalink:  ../20190124144732.GD8334@momjian.us/
Also on:    postgresql.org/message-id/20190124144732.GD8334@momjian.us

 · 

reply

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: bruce@momjian.us, horiguchi.kyotaro@lab.ntt.co.jp, tsunakawa.takay@jp.fujitsu.com, GavinFlower@archidevsys.co.nz, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, ideriha.takeshi@jp.fujitsu.com, pgsql-hackers@lists.postgresql.org, alvherre@alvh.no-ip.org, andres@anarazel.de, 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: <20190124144732.GD8334@momjian.us>

* 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