RE: Protect syscache from bloating with negative cache entries

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
Date: 2019-02-27 05:26:57
Message-ID: 4E72940DA2BF16479384A86D54D0988A6F441D20@G01JPEXMBKW04
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

>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
>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.

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

Takeshi Ideriha

In response to


Browse pgsql-hackers by date

  From Date Subject
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