Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Cc: alex work <alexwork033@gmail.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2024-03-21T19:42:14Z
Lists: pgsql-hackers, pgsql-general
Attachments
- v1-use-hash-table-for-CatCLists.patch (text/x-diff) patch v1
I wrote: > It looks like part of the blame might be ascribable to catcache.c, > as if you look at the problem microscopically you find that > roles_is_member_of is causing catcache to make a ton of AUTHMEMMEMROLE > catcache lists, and SearchSysCacheList is just iterating linearly > through the cache's list-of-lists, so that search is where the O(N^2) > time is actually getting taken. Up to now that code has assumed that > any one catcache would not have very many catcache lists. Maybe it's > time to make that smarter; but since we've gotten away with this > implementation for decades, I can't help feeling that the real issue > is with roles_is_member_of's usage pattern. I wrote a quick finger exercise to make catcache.c use a hash table instead of a single list for CatCLists, modeling it closely on the existing hash logic for simple catcache entries. This helps a good deal, but I still see the problematic GRANT taking ~250ms, compared to 5ms in v15. roles_is_member_of is clearly on the hook for that. regards, tom lane
Commits
-
Optimize roles_is_member_of() with a Bloom filter.
- d365ae705409 17.0 landed
-
Use a hash table for catcache.c's CatCList objects.
- 473182c9523a 17.0 landed
- 14e991db89b1 16.3 landed