Re: [PATCH] Runtime control of CLOBBER_CACHE_ALWAYS - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [PATCH] Runtime control of CLOBBER_CACHE_ALWAYS
Date
Msg-id 5d720d8a-6d58-6b89-279b-aef10e3088d0@2ndquadrant.com
Whole thread Raw
In response to Re: [PATCH] Runtime control of CLOBBER_CACHE_ALWAYS  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: [PATCH] Runtime control of CLOBBER_CACHE_ALWAYS  (Craig Ringer <craig.ringer@enterprisedb.com>)
List pgsql-hackers
On 2020-12-03 07:01, Craig Ringer wrote:
> To try it out, apply the patch (git am), build with --enable-cassert, 
> then compare:
> 
>     make -C src/test/regress check
> 
> and
> 
>     PGOPTIONS="-c debug_clobber_cache_depth=1" \
>     make -C src/test/regress check
> 
> The speed difference will be obvious if nothing else!

This is a really useful feature change.  I have a version that I'm happy 
to commit, but I wanted to check on the name of the setting.  The 
proposed name arose during the discussion when it was just to set the 
recursion depth but not enable the feature altogether, so I think that 
name is a bit misleading now.  We could reuse the old macro name, as in 
clobber_cache_always=N, which is very recognizable.  But the feature 
itself doesn't clobber anything (that's done by CLOBBER_FREED_MEMORY), 
so most accurate would be something like 
invalidate_system_caches_always=N.  Thoughts?

-- 
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: PoC/WIP: Extended statistics on expressions
Next
From: Tomas Vondra
Date:
Subject: Re: PoC/WIP: Extended statistics on expressions