RE: Protect syscache from bloating with negative cache entries
От | Tsunakawa, Takayuki |
---|---|
Тема | RE: Protect syscache from bloating with negative cache entries |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1FB9ECBC@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Re: Protect syscache from bloating with negative cache entries (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
RE: Protect syscache from bloating with negative cache entries
Re: Protect syscache from bloating with negative cache entries |
Список | pgsql-hackers |
From: Robert Haas [mailto:robertmhaas@gmail.com] > That might be enough to justify having the parameter. But I'm not > quite sure how high the value would need to be set to actually get the > benefit in a case like that, or what happens if you set it to a value > that's not quite high enough. I think it might be good to play around > some more with cases like this, just to get a feeling for how much > time you can save in exchange for how much memory. Why don't we consider this just like the database cache and other DBMS's dictionary caches? That is, * If you want to avoid infinite memory bloat, set the upper limit on size. * To find a better limit, check the hit ratio with the statistics view (based on Horiguchi-san's original 0004 patch, althoughthat seems modification anyway) Why do people try to get away from a familiar idea... Am I missing something? Ideriha-san, Could you try simplifying the v15 patch set to see how simple the code would look or not? That is: * 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 Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: