| From: | "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com> |
|---|---|
| To: | "'bruce(at)momjian(dot)us'" <bruce(at)momjian(dot)us>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
| 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>, "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:43:22 |
| Message-ID: | 4E72940DA2BF16479384A86D54D0988A6F41C019@G01JPEXMBKW04 |
| 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.
One idea is building list with access counter for implementing LRU list based on this current patch.
The list is ordered by last access time. When a catcache entry is referenced, the list is maintained
, which is just manipulation of pointers at several times.
As Bruce mentioned, it's not shared so there is no cost related to lock contention.
When it comes to pruning, the cache older than certain timestamp with zero access counter is pruned.
This way would improve performance because it only scans limited range (bounded by sys_cache_min_age).
Current patch scans all hash entries and check each timestamp which would decrease the performance as cache size grows.
I'm thinking hopefully implementing this idea and measuring the performance.
And when we want to set the memory size limit as Tsunakawa san said, the LRU list would be suitable.
Regards,
Takeshi Ideriha
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2019-02-05 03:04:15 | Re: WIP: Avoid creation of the free space map for small tables |
| Previous Message | Tsunakawa, Takayuki | 2019-02-05 02:40:35 | RE: Protect syscache from bloating with negative cache entries |