Re: Protect syscache from bloating with negative cache entries

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com
Cc: GavinFlower(at)archidevsys(dot)co(dot)nz, bruce(at)momjian(dot)us, robertmhaas(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, alvherre(at)alvh(dot)no-ip(dot)org, andres(at)anarazel(dot)de, michael(dot)paquier(at)gmail(dot)com, david(at)pgmasters(dot)net, Jim(dot)Nasby(at)bluetreble(dot)com, craig(at)2ndquadrant(dot)com
Subject: Re: Protect syscache from bloating with negative cache entries
Date: 2019-01-21 08:22:55
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Thank you for pointing out the stupidity. (Tom did earlier, though.)

At Mon, 21 Jan 2019 07:12:41 +0000, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote in <0A3221C70F24FB45833433255569204D1FB6C78A(at)G01JPEXMBYT05>
> From: Kyotaro HORIGUCHI [mailto:horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp]
> > 0003: Remote GUC setting
> >
> > It is independent from the above two, and heavily arguable.
> >
> > pg_set_backend_config(pid, name, value) changes the GUC <name> on the
> > backend with <pid> to <value>.
> >
> Not having looked at the code yet, why did you think this is necessary? Can't we always collect the cache stats? Is it heavy due to some locking in the shared memory, or sending the stats to the stats collector?

Yeah, I had a fun making it but I don't think it can be said very
good. I must admit that it is a kind of too-much or something

Anyway it needs to scan the whole hash to collect numbers and I
don't see how to elimite the complexity without a penalty on
regular code paths for now. I don't want do that always for the

An option is an additional PGPROC member and interface functions.

struct PGPROC
int syscahe_usage_track_interval; /* track interval, 0 to disable */

=# select syscahce_usage_track_add(<pid>, <intvl>[, <repetition>]);
=# select syscahce_usage_track_remove(2134);

Or, just provide an one-shot triggering function.

=# select syscahce_take_usage_track(<pid>);

This can use both a similar PGPROC variable or SendProcSignal()
but the former doesn't fire while idle time unless using timer.

Any thoughts?


Kyotaro Horiguchi
NTT Open Source Software Center

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2019-01-21 08:23:04 Re: partitioned tables referenced by FKs
Previous Message Amit Langote 2019-01-21 08:21:46 Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0