diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2021-07-05 16:51:57 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2021-07-05 16:51:57 -0400 |
commit | 2f487116e9988615d05a6c380c3ff8fa8a4286f8 (patch) | |
tree | e551a81c5e7576f2403545bf53eb3147f363f6a8 /contrib/postgres_fdw/postgres_fdw.c | |
parent | 27621cc55526fc5acb58bc6c023e79fba3a92672 (diff) | |
download | postgresql-2f487116e9988615d05a6c380c3ff8fa8a4286f8.tar.gz postgresql-2f487116e9988615d05a6c380c3ff8fa8a4286f8.zip |
Reduce overhead of cache-clobber testing in LookupOpclassInfo().
Commit 03ffc4d6d added logic to bypass all caching behavior in
LookupOpclassInfo when CLOBBER_CACHE_ALWAYS is enabled. It doesn't
look like I stopped to think much about what that would cost, but
recent investigation shows that the cost is enormous: it roughly
doubles the time needed for cache-clobber test runs.
There does seem to be value in this behavior when trying to test
the opclass-cache loading logic itself, but for other purposes the
cost is excessive. Hence, let's back off to doing this only when
debug_invalidate_system_caches_always is at least 3; or in older
branches, when CLOBBER_CACHE_RECURSIVELY is defined.
While here, clean up some other minor issues in LookupOpclassInfo.
Re-order the code so we aren't left with broken cache entries (leading
to later core dumps) in the unlikely case that we suffer OOM while
trying to allocate space for a new entry. (That seems to be my
oversight in 03ffc4d6d.) Also, in >= v13, stop allocating one array
entry too many. That's evidently left over from sloppy reversion in
851b14b0c.
Back-patch to all supported branches, mainly to reduce the runtime
of cache-clobbering buildfarm animals.
Discussion: https://postgr.es/m/1370856.1625428625@sss.pgh.pa.us
Diffstat (limited to 'contrib/postgres_fdw/postgres_fdw.c')
0 files changed, 0 insertions, 0 deletions