RE: Protect syscache from bloating with negative cache entries
От | Tsunakawa, Takayuki |
---|---|
Тема | RE: Protect syscache from bloating with negative cache entries |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1FBBA5B4@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | 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] > 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 > I'm afraid the measurement is not correct. First, the older discussion below shows that the accounting overhead is much,much smaller, even with a more complex accounting. 9.5: Better memory accounting, towards memory-bounded HashAg https://www.postgresql.org/message-id/flat/1407012053.15301.53.camel%40jeff-desktop Second, allocation/free of memory > 8 KB calls malloc()/free(). I guess the accounting overhead will be more likely to behidden under the overhead of malloc() and free(). What we'd like to know the overhead when malloc() and free() are notcalled. And are you sure you didn't enable assert checking? Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: