pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Ideriha, Takeshi <ideriha.takeshi@jp.fujitsu.com>
To: 'bruce@momjian.us' <bruce@momjian.us>
To: Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>
Cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: GavinFlower@archidevsys.co.nz <GavinFlower@archidevsys.co.nz>
Cc: robertmhaas@gmail.com <robertmhaas@gmail.com>
Cc: tgl@sss.pgh.pa.us <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Cc: alvherre@alvh.no-ip.org <alvherre@alvh.no-ip.org>
Cc: andres@anarazel.de <andres@anarazel.de>
Cc: michael.paquier@gmail.com <michael.paquier@gmail.com>
Cc: david@pgmasters.net <david@pgmasters.net>
Cc: Jim.Nasby@bluetreble.com <Jim.Nasby@bluetreble.com>
Cc: craig@2ndquadrant.com <craig@2ndquadrant.com>
Subject: Re: Protect syscache from bloating with negative cache entries
Date: Tue, 5 Feb 2019 18:27:52 +0100
Message-ID: <ec91c81f-c1a5-e4fe-e344-cef963aecfd7@2ndquadrant.com> (raw)
In-Reply-To: <4E72940DA2BF16479384A86D54D0988A6F41C019@G01JPEXMBKW04>
References: <0A3221C70F24FB45833433255569204D1FB70EFB@G01JPEXMBYT05>
	<20190128.124650.227901198.horiguchi.kyotaro@lab.ntt.co.jp>
	<4E72940DA2BF16479384A86D54D0988A6F4156D4@G01JPEXMBKW04>
	<20190130.173220.35762657.horiguchi.kyotaro@lab.ntt.co.jp>
	<0A3221C70F24FB45833433255569204D1FB93590@G01JPEXMBYT05>
	<20190204224318.GA32538@momjian.us>
	<4E72940DA2BF16479384A86D54D0988A6F41C019@G01JPEXMBKW04>

Hi,

I find it a bit surprising there are almost no results demonstrating the
impact of the proposed changes on some typical workloads. It touches
code (syscache, ...) that is quite sensitive performance-wise, and
adding even just a little bit of overhead may hurt significantly. Even
on systems that don't have issues with cache bloat, etc.

I think this is something we need - benchmarks measuring the overhead on
a bunch of workloads (both typical and corner cases). Especially when
there was a limit on cache size in the past, and it was removed because
it was too expensive / hurting in some cases. I can't imagine committing
any such changes without this information.

This is particularly important as the patch was about one particular
issue (bloat due to negative entries) initially, but then the scope grew
quite a it. AFAICS the thread now talks about these workloads:

* negative entries (due to search_path lookups etc.)
* many tables accessed randomly
* many tables with only a small subset accessed frequently
* many tables with subsets accessed in subsets (due to pooling)
* ...

Unfortunately, some of those cases seems somewhat contradictory (i.e.
what works for one hurts the other), so I doubt it's possible to improve
all of them at once. But that makes the bencharking even more important.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




view thread (272+ messages)  latest in thread

Message-ID: <ec91c81f-c1a5-e4fe-e344-cef963aecfd7@2ndquadrant.com>
Permalink:  ../ec91c81f-c1a5-e4fe-e344-cef963aecfd7@2ndquadrant.com/
Also on:    postgresql.org/message-id/ec91c81f-c1a5-e4fe-e344-cef963aecfd7@2ndquadrant.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tomas.vondra@2ndquadrant.com, ideriha.takeshi@jp.fujitsu.com, bruce@momjian.us, tsunakawa.takay@jp.fujitsu.com, horiguchi.kyotaro@lab.ntt.co.jp, GavinFlower@archidevsys.co.nz, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org, alvherre@alvh.no-ip.org, andres@anarazel.de, michael.paquier@gmail.com, david@pgmasters.net, Jim.Nasby@bluetreble.com, craig@2ndquadrant.com
  Subject: Re: Protect syscache from bloating with negative cache entries
  In-Reply-To: <ec91c81f-c1a5-e4fe-e344-cef963aecfd7@2ndquadrant.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox