|From:||Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>|
|Cc:||tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com, alvherre(at)2ndquadrant(dot)com, tomas(dot)vondra(at)2ndquadrant(dot)com, 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, michael(dot)paquier(at)gmail(dot)com, david(at)pgmasters(dot)net, craig(at)2ndquadrant(dot)com|
|Subject:||Re: Protect syscache from bloating with negative cache entries|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
At Thu, 14 Feb 2019 00:40:10 -0800, Andres Freund <andres(at)anarazel(dot)de> wrote in <20190214084010(dot)bdn6tmba2j7szo3m(at)alap3(dot)anarazel(dot)de>
> On 2019-02-13 15:31:14 +0900, Kyotaro HORIGUCHI wrote:
> > Instead, I added an accounting(?) interface function.
> > | MemoryContextGettConsumption(MemoryContext cxt);
> > The API returns the current consumption in this memory
> > context. This allows "real" memory accounting almost without
> > overhead.
> That's definitely *NOT* almost without overhead. This adds additional
> instructions to one postgres' hottest set of codepaths.
I'm not sure how much the two instructions in AllocSetAlloc
actually impacts, but I agree that it is doubtful that the
size-limit feature worth the possible slowdown in any extent.
# I faintly remember that I tried the same thing before..
> I think you're not working incrementally enough here. I strongly suggest
> solving the negative cache entry problem, and then incrementally go from
> there after that's committed. The likelihood of this patch ever getting
> merged otherwise seems extremely small.
Mmm. Scoping to the negcache prolem, my very first patch posted
two-years ago does that based on invalidation for pg_statistic
and pg_class, like I think Tom have suggested somewhere in this
This is completely different approach from the current shape and
it would be useless after pruning is introduced. So I'd like to
go for the generic pruning by age.
Difference from v15:
Removed AllocSet accounting stuff. We use approximate memory
size for catcache.
Removed prune-by-number(or size) stuff.
Adressing comments from Tsunakawa-san and Ideriha-san .
Separated catcache monitoring feature. (Removed from this set)
(But it is crucial to check this feature...)
Is this small enough ?
NTT Open Source Software Center
|Next Message||Haribabu Kommi||2019-02-20 04:16:48||Re: pg_basebackup ignores the existing data directory permissions|
|Previous Message||Masahiko Sawada||2019-02-20 04:00:13||Re: Copy function for logical replication slots|