Re: Protect syscache from bloating with negative cache entries

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com
Cc: bruce(at)momjian(dot)us, GavinFlower(at)archidevsys(dot)co(dot)nz, robertmhaas(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)lists(dot)postgresql(dot)org, alvherre(at)alvh(dot)no-ip(dot)org, andres(at)anarazel(dot)de, michael(dot)paquier(at)gmail(dot)com, david(at)pgmasters(dot)net, Jim(dot)Nasby(at)bluetreble(dot)com, ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com, craig(at)2ndquadrant(dot)com
Subject: Re: Protect syscache from bloating with negative cache entries
Date: 2019-02-06 08:37:04
Message-ID: 20190206.173704.60970821.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Wed, 06 Feb 2019 15:16:53 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20190206(dot)151653(dot)117382256(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
> > The two should have the same extent of impact on performance when
> > disabled. I'll take numbers briefly using pgbench.

(pgbench -j 10 -c 10 -T 120) x 5 times for each.

A: unpached : 118.58 tps (stddev 0.44)
B: pached-not-used[1] : 118.41 tps (stddev 0.29)
C: patched-timedprune[2]: 118.41 tps (stddev 0.51)
D: patched-capped...... : none[3]

[1]: cache_prune_min_age = 0, cache_entry_limit = 0

[2]: cache_prune_min_age = 100, cache_entry_limit = 0
(Prunes every 100ms)

[3] I didin't find a sane benchmark for the capping case using
vanilla pgbench.

It doesn't seem to me showing significant degradation on *my*
box...

# I found a bug that can remove newly created entry. So v11.

regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
v11-0001-Remove-entries-that-haven-t-been-used-for-a-certain-.patch text/x-patch 15.3 KB
v11-0002-Syscache-usage-tracking-feature.patch text/x-patch 37.7 KB
v11-0003-PoC-add-prune-by-number-of-entries-feature.patch text/x-patch 6.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-02-06 08:39:43 Re: Tighten up a few overly lax regexes in pg_dump's tap tests
Previous Message Tsunakawa, Takayuki 2019-02-06 08:29:54 RE: Cache relation sizes?