| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | 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 |
| Date: | 2019-02-14 08:40:10 |
| Message-ID: | 20190214084010.bdn6tmba2j7szo3m@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
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 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.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-02-14 08:42:18 | Re: WAL insert delay settings |
| Previous Message | Ideriha, Takeshi | 2019-02-14 08:25:46 | RE: Protect syscache from bloating with negative cache entries |