Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rnLmY-00CqQM-D0 for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Mar 2024 17:00:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rnLmW-00ErCD-RY for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Mar 2024 17:00:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rnLmW-00ErC5-Id for pgsql-hackers@lists.postgresql.org; Thu, 21 Mar 2024 17:00:45 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rnLmT-005l4J-6F for pgsql-hackers@lists.postgresql.org; Thu, 21 Mar 2024 17:00:44 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 42LH0dvK351384; Thu, 21 Mar 2024 13:00:39 -0400 From: Tom Lane To: pgsql-hackers@lists.postgresql.org cc: alex work , Robert Haas Subject: Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs In-reply-to: <341186.1711037256@sss.pgh.pa.us> References: <341186.1711037256@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Thu, 21 Mar 2024 12:07:36 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <351382.1711040439.1@sss.pgh.pa.us> Date: Thu, 21 Mar 2024 13:00:39 -0400 Message-ID: <351383.1711040439@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > I poked into this a bit. It seems the problem is that as of v16, we > try to search for the "best" role membership path from the current > user to the target role, and that's done in a very brute-force way, > as a side effect of computing the set of *all* role memberships the > current role has. Actually, roles_is_member_of sucks before v16 too; the new thing is only that it's being invoked during GRANT ROLE. Using the roles created by the given test case, I see in v15: $ psql psql (15.6) Type "help" for help. regression=# drop table at; DROP TABLE regression=# set role a_0010308; SET regression=> create table at(f1 int); CREATE TABLE regression=> \timing Timing is on. regression=> set role acc; SET Time: 0.493 ms regression=> insert into at values(1); INSERT 0 1 Time: 3565.029 ms (00:03.565) regression=> insert into at values(1); INSERT 0 1 Time: 2.308 ms So it takes ~3.5s to populate the roles_is_member_of cache for "acc" given this membership set. This is actually considerably worse than in v16 or HEAD, where the same test takes about 1.6s for me. Apparently the OP has designed their use-case so that they dodge these implementation problems in v15 and earlier, but that's a far cry from saying that there were no problems with lots-o-roles before v16. regards, tom lane