From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Subject: Re: Excessive cost of OpClassCache flushes in CLOBBER_CACHE_ALWAYS mode
Date: Mon, 5 Jul 2021 07:32:08 -0400
Message-ID: <8a392a8d-d520-d8d0-5e11-ff421a4c8e23@dunslane.net> (raw)
In-Reply-To: <1370856.1625428625@sss.pgh.pa.us>
References: <1370856.1625428625@sss.pgh.pa.us>
On 7/4/21 3:57 PM, Tom Lane wrote:
> Over in [1] it is demonstrated that with CLOBBER_CACHE_ALWAYS enabled,
> initdb accounts for a full 50% of the runtime of "make check-world"
> (well, actually of the buildfarm cycle, which is not quite exactly
> that but close). Since initdb certainly doesn't cost that much
> normally, I wondered why it is so negatively affected by CCA. Some
> perf measuring led me to LookupOpclassInfo, and specifically this bit:
>
> /*
> * When testing for cache-flush hazards, we intentionally disable the
> * operator class cache and force reloading of the info on each call. This
> * is helpful because we want to test the case where a cache flush occurs
> * while we are loading the info, and it's very hard to provoke that if
> * this happens only once per opclass per backend.
> */
> #ifdef CLOBBER_CACHE_ENABLED
> if (debug_invalidate_system_caches_always > 0)
> opcentry->valid = false;
> #endif
>
> Diking that out halves initdb's CCA runtime. Turns out it also
> roughly halves the runtime of the core regression tests under CCA,
> so this doesn't explain why initdb seems so disproportionately
> affected by CCA.
>
> However, seeing that this single choice is accounting for half the
> cost of CCA testing, we really have to ask whether it's worth that.
> This code was added by my commit 03ffc4d6d of 2007-11-28, about which
> I wrote:
>
> Improve test coverage of CLOBBER_CACHE_ALWAYS by having it also force
> reloading of operator class information on each use of LookupOpclassInfo.
> Had this been in place a year ago, it would have helped me find a bug
> in the then-new 'operator family' code. Now that we have a build farm
> member testing CLOBBER_CACHE_ALWAYS on a regular basis, it seems worth
> expending a little bit of effort here.
>
> I'm now a little dubious about my claim that this would have helped find
> any bugs. Invalidating a finished OpClassCache entry does not model any
> real-world scenario, because as noted elsewhere in LookupOpclassInfo,
> once such a cache entry is populated it is kept for the rest of the
> session. Also, the claim in the comment that we need this to test
> a cache flush during load seems like nonsense: if we have
> debug_invalidate_system_caches_always turned on, then we'll test
> the effects of such flushes throughout the initial population of
> a cache entry. Doing it over and over again adds nothing.
>
> So I'm now fairly strongly tempted to remove this code outright
> (effectively reverting 03ffc4d6d). Another possibility now that
> we have debug_invalidate_system_caches_always is to increase the
> threshold at which this happens, making it more like
> CLOBBER_CACHE_RECURSIVE.
>
> Thoughts?
>
>
If we don't think it's adding anything useful just rip it out. We don't
generally keep code hanging around just on the off chance it might be
useful some day.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
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: andrew@dunslane.net, tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org
Subject: Re: Excessive cost of OpClassCache flushes in CLOBBER_CACHE_ALWAYS mode
In-Reply-To: <8a392a8d-d520-d8d0-5e11-ff421a4c8e23@dunslane.net>
* 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