From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Runtime control of CLOBBER_CACHE_ALWAYS |
Date: | 2021-01-05 14:40:56 |
Message-ID: | 5d720d8a-6d58-6b89-279b-aef10e3088d0@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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/
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2021-01-05 15:09:19 | Re: PoC/WIP: Extended statistics on expressions |
Previous Message | Dean Rasheed | 2021-01-05 14:10:08 | Re: PoC/WIP: Extended statistics on expressions |