RE: Protect syscache from bloating with negative cache entries
От | Ideriha, Takeshi |
---|---|
Тема | RE: Protect syscache from bloating with negative cache entries |
Дата | |
Msg-id | 4E72940DA2BF16479384A86D54D0988A6F441D20@G01JPEXMBKW04 обсуждение исходный текст |
Ответ на | RE: Protect syscache from bloating with negative cache entries ("Ideriha, Takeshi" <ideriha.takeshi@jp.fujitsu.com>) |
Ответы |
RE: Protect syscache from bloating with negative cache entries
|
Список | pgsql-hackers |
>From: Ideriha, Takeshi [mailto:ideriha.takeshi@jp.fujitsu.com] >>>* 0001: add dlist_push_tail() ... as is >>>* 0002: memory accounting, with correction based on feedback >>>* 0003: merge the original 0003 and 0005, with correction based on >>>feedback >> >>Attached are simpler version based on Horiguchi san's ver15 patch, >>which means cache is pruned by both time and size. >>(Still cleanup function is complex but it gets much simpler.) > >I don't mean to disregard what Horiguchi san and others have developed and >discussed. >But I refactored again the v15 patch to reduce complexity of v15 patch because it >seems to me one of the reason for dropping feature for pruning by size stems from >code complexity. > >Another thing is there's been discussed about over memory accounting overhead but >the overhead effect hasn't been measured in this thread. So I'd like to measure it. I measured the memory context accounting overhead using Tomas's tool palloc_bench, which he made it a while ago in the similar discussion. https://www.postgresql.org/message-id/53F7E83C.3020304@fuzzy.cz This tool is a little bit outdated so I fixed it but basically I followed him. Things I did: - make one MemoryContext - run both palloc() and pfree() for 32kB area 1,000,000 times. - And measure this time The result shows that master is 30 times faster than patched one. So as Andres mentioned in upper thread it seems it has overhead. [master (without v15 patch)] 61.52 ms 60.96 ms 61.40 ms 61.42 ms 61.14 ms [with v15 patch] 1838.02 ms 1754.84 ms 1755.83 ms 1789.69 ms 1789.44 ms Regards, Takeshi Ideriha
В списке pgsql-hackers по дате отправления: