RE: Protect syscache from bloating with negative cache entries

Поиск
Список
Период
Сортировка
От Ideriha, Takeshi
Тема RE: Protect syscache from bloating with negative cache entries
Дата
Msg-id 4E72940DA2BF16479384A86D54D0988A6F41C019@G01JPEXMBKW04
обсуждение исходный текст
Ответ на Re: Protect syscache from bloating with negative cache entries  ("bruce@momjian.us" <bruce@momjian.us>)
Ответы Re: Protect syscache from bloating with negative cache entries  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
>From: bruce@momjian.us [mailto:bruce@momjian.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Tsunakawa, Takayuki"
Дата:
Сообщение: RE: Protect syscache from bloating with negative cache entries
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: WIP: Avoid creation of the free space map for small tables