| 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 |
| Message-ID: | 20190306.130502.255198860.horiguchi.kyotaro@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello.
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.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
| 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 |