Re: Protect syscache from bloating with negative cache entries

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com
Cc: tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com, andres(at)anarazel(dot)de, alvherre(at)2ndquadrant(dot)com, tomas(dot)vondra(at)2ndquadrant(dot)com, bruce(at)momjian(dot)us, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)lists(dot)postgresql(dot)org, michael(dot)paquier(at)gmail(dot)com, robertmhaas(at)gmail(dot)com, david(at)pgmasters(dot)net, craig(at)2ndquadrant(dot)com
Subject: Re: Protect syscache from bloating with negative cache entries
Date: 2019-03-06 04:05:02
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


At Mon, 4 Mar 2019 03:03:51 +0000, "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com> wrote in <4E72940DA2BF16479384A86D54D0988A6F44564E(at)G01JPEXMBKW04>
> Does this result show that hard-limit size option with memory accounting
> doesn't harm to usual users who disable hard limit size option?

Not sure, but 4% seems beyond noise level. Planner requests
mainly smaller allocation sizes especially for list
operations. If we implement it for slab allocator, the
degradation would be more significant.

We *are* suffering from endless bloat of system cache (and some
other stuffs) and there is no way to deal with it. The soft limit
feature actually eliminates the problem with no degradation and
even accelerates execution in some cases.

Infinite bloat is itself a problem, but if the processes just
needs more but finite size of memory, just additional memory or
less max_connections is enough.

What Andres and Robert suggested is we need more convincing
reason for the hard limit feature other than "some is wanting
it". The degradation of the crude accounting stuff is not the
primary issue here. I think.


Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2019-03-06 04:11:26 Re: Converting NOT IN to anti-joins during planning
Previous Message Etsuro Fujita 2019-03-06 04:04:28 Re: Update does not move row across foreign partitions in v11