Re: Protect syscache from bloating with negative cache entries

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: alvherre(at)2ndquadrant(dot)com
Cc: tomas(dot)vondra(at)2ndquadrant(dot)com, bruce(at)momjian(dot)us, andres(at)anarazel(dot)de, robertmhaas(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com, michael(dot)paquier(at)gmail(dot)com, david(at)pgmasters(dot)net, craig(at)2ndquadrant(dot)com
Subject: Re: Protect syscache from bloating with negative cache entries
Date: 2019-02-07 12:18:45
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

At Thu, 07 Feb 2019 15:24:18 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20190207(dot)152418(dot)139132570(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
> I'm going to retake numbers with search-only queries.

Yeah, I was stupid.

I made a rerun of benchmark using "-S -T 30" on the server build
with no assertion and -O2. The numbers are the best of three
successive attempts. The patched version is running with
cache_target_memory = 0, cache_prune_min_age = 600 and
cache_entry_limit = 0 but pruning doesn't happen by the workload.

master: 13393 tps
v12 : 12625 tps (-6%)

Significant degradation is found.

Recuded frequency of dlist_move_tail by taking 1ms interval
between two succesive updates on the same entry let the
degradation dissapear.

patched : 13720 tps (+2%)

I think there's still no need of such frequency. It is 100ms in
the attched patch.

# I'm not sure the name LRU_IGNORANCE_INTERVAL makes sens..

The attached


Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
v13-0001-Add-dlist_move_tail.patch text/x-patch 1.2 KB
v13-0002-Remove-entries-that-haven-t-been-used-for-a-certain-.patch text/x-patch 17.4 KB
v13-0003-Syscache-usage-tracking-feature.patch text/x-patch 35.5 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2019-02-07 12:55:18 Re: Problem while updating a foreign table pointing to a partitioned table on foreign server
Previous Message Michael Paquier 2019-02-07 12:18:04 Re: [HACKERS] REINDEX CONCURRENTLY 2.0