Re: Protect syscache from bloating with negative cache entries

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Protect syscache from bloating with negative cache entries
Дата
Msg-id 20190206084705.wh5mltzyt77fkkse@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Protect syscache from bloating with negative cache entries  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
On 2019-02-06 17:37:04 +0900, Kyotaro HORIGUCHI wrote:
> At Wed, 06 Feb 2019 15:16:53 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote
in<20190206.151653.117382256.horiguchi.kyotaro@lab.ntt.co.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.

This seems to just benchmark your disk speed, no? ISTM you need to
measure readonly performance, not read/write. And with plenty more
tables than just standard pgbench -S.

Greetings,

Andres Freund


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Tighten up a few overly lax regexes in pg_dump's tap tests
Следующее
От: "Jamison, Kirk"
Дата:
Сообщение: RE: Cache relation sizes?