|From:||"Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com>|
|To:||"Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, 'Robert Haas' <robertmhaas(at)gmail(dot)com>, "David Steele" <david(at)pgmasters(dot)net>, Craig Ringer <craig(at)2ndquadrant(dot)com>|
|Subject:||RE: Protect syscache from bloating with negative cache entries|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
>From: Ideriha, Takeshi [mailto:ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)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
>>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
>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
>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.
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)]
[with v15 patch]
|Next Message||Markus Winand||2019-02-27 05:36:43||Re: Index INCLUDE vs. Bitmap Index Scan|
|Previous Message||Michael Paquier||2019-02-27 05:21:52||Re: TupleTableSlot abstraction|