From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | "'bruce(at)momjian(dot)us'" <bruce(at)momjian(dot)us> |
Cc: | 'Kyotaro HORIGUCHI' <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "GavinFlower(at)archidevsys(dot)co(dot)nz" <GavinFlower(at)archidevsys(dot)co(dot)nz>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "alvherre(at)alvh(dot)no-ip(dot)org" <alvherre(at)alvh(dot)no-ip(dot)org>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "michael(dot)paquier(at)gmail(dot)com" <michael(dot)paquier(at)gmail(dot)com>, "david(at)pgmasters(dot)net" <david(at)pgmasters(dot)net>, "Jim(dot)Nasby(at)bluetreble(dot)com" <Jim(dot)Nasby(at)bluetreble(dot)com>, "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com>, "craig(at)2ndquadrant(dot)com" <craig(at)2ndquadrant(dot)com> |
Subject: | RE: Protect syscache from bloating with negative cache entries |
Date: | 2019-02-05 02:40:35 |
Message-ID: | 0A3221C70F24FB45833433255569204D1FB93A16@G01JPEXMBYT05 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: bruce(at)momjian(dot)us [mailto:bruce(at)momjian(dot)us]
> On Mon, Feb 4, 2019 at 08:23:39AM +0000, Tsunakawa, Takayuki wrote:
> > Horiguchi-san, Bruce, all, So, why don't we make
> > syscache_memory_target the upper limit on the total size of all
> > catcaches, and rethink the past LRU management?
>
> I was going to say that our experience with LRU has been that the
> overhead is not worth the value, but that was in shared resource cases,
> which this is not.
That's good news! Then, let's proceed with the approach involving LRU, Horiguchi-san, Ideriha-san.
Regards
Takayuki Tsunakawa
From | Date | Subject | |
---|---|---|---|
Next Message | Ideriha, Takeshi | 2019-02-05 02:43:22 | RE: Protect syscache from bloating with negative cache entries |
Previous Message | Michael Paquier | 2019-02-05 01:41:19 | Re: Tighten up a few overly lax regexes in pg_dump's tap tests |