RE: Protect syscache from bloating with negative cache entries
От | Ideriha, Takeshi |
---|---|
Тема | RE: Protect syscache from bloating with negative cache entries |
Дата | |
Msg-id | 4E72940DA2BF16479384A86D54D0988A6F443F43@G01JPEXMBKW04 обсуждение исходный текст |
Ответ на | RE: Protect syscache from bloating with negative cache entries ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>) |
Ответы |
RE: Protect syscache from bloating with negative cache entries
|
Список | pgsql-hackers |
>From: Tsunakawa, Takayuki [mailto:tsunakawa.takay@jp.fujitsu.com] >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 >And are you sure you didn't enable assert checking? Ah, sorry.. I misconfigured it. >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. >Second, allocation/free of memory > 8 KB calls malloc()/free(). I guess the >accounting overhead will be more likely to be hidden under the overhead of malloc() >and free(). What we'd like to know the overhead when malloc() and free() are not >called. Here is the average of 50 times measurement. Palloc-pfree for 800byte with 1,000,000 times, and 32kB with 1,000,000 times. I checked malloc is not called at size=800 using gdb. [Size=800, iter=1,000,000] Master |15.763 Patched|16.262 (+3%) [Size=32768, iter=1,000,000] Master |61.3076 Patched|62.9566 (+2%) At least compared to previous HashAg version, the overhead is smaller. It has some overhead but is increase by 2 or 3% a little bit? Regards, Takeshi Ideriha
В списке pgsql-hackers по дате отправления: