aboutsummaryrefslogtreecommitdiff
path: root/contrib/postgres_fdw/postgres_fdw.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2024-03-22 17:13:53 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2024-03-22 17:13:53 -0400
commit14e991db89b1e0fd39e8875b80da7f0b0c3533a4 (patch)
tree27ce5b02dd5078f567df71b408ca430fc5d94e20 /contrib/postgres_fdw/postgres_fdw.c
parent5863bacb87c1e6cd1a322c9c4a5a861b27768379 (diff)
downloadpostgresql-14e991db89b1e0fd39e8875b80da7f0b0c3533a4.tar.gz
postgresql-14e991db89b1e0fd39e8875b80da7f0b0c3533a4.zip
Use a hash table for catcache.c's CatCList objects.
Up to now, all of the "catcache list" objects within a catalog cache were just chained together on a single dlist, requiring O(N) time to search. Remarkably, we've not had serious performance problems with that so far; but we got a complaint of a bad performance regression from v15 in a case with a large number of roles in the system, which traced down to O(N^2) total time when we probed N catcache lists. Replace that data structure with a hashtable having an enlargeable number of dlists, in an exactly parallel way to the data structure we've used for years for the plain CatCTup cache members. The extra cost of maintaining a hash table seems negligible, since we were already computing a hash value for list searches. Normally this'd be HEAD-only material, but in view of the performance regression it seems advisable to back-patch into v16. In the v16 version of the patch, leave the dead cc_lists field where it is and add the new fields at the end of struct catcache, to avoid possible ABI breakage in case any external code is looking at these structs. (We assume no external code is actually allocating new catcache structs.) Per report from alex work. Discussion: https://postgr.es/m/CAGvXd3OSMbJQwOSc-Tq-Ro1CAz=vggErdSG7pv2s6vmmTOLJSg@mail.gmail.com
Diffstat (limited to 'contrib/postgres_fdw/postgres_fdw.c')
0 files changed, 0 insertions, 0 deletions