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>
Subject: Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs
In-reply-to: <619340.1711050134@sss.pgh.pa.us>
References: <CAGvXd3OSMbJQwOSc-Tq-Ro1CAz=vggErdSG7pv2s6vmmTOLJSg@mail.gmail.com> <341186.1711037256@sss.pgh.pa.us> <619340.1711050134@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Thu, 21 Mar 2024 15:42:14 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <642441.1711053105.1@sss.pgh.pa.us>
Date: Thu, 21 Mar 2024 16:31:45 -0400
Message-ID: <642442.1711053105@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/642442.1711053105%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> ... I still see the problematic GRANT taking ~250ms, compared
> to 5ms in v15.  roles_is_member_of is clearly on the hook for that.

Ah: looks like that is mainly the fault of the list_append_unique_oid
calls in roles_is_member_of.  That's also an O(N^2) cost of course,
though with a much smaller constant factor.

I don't think we have any really cheap way to de-duplicate the role
OIDs, especially seeing that it has to be done on-the-fly within the
collection loop, and the order of roles_list is at least potentially
interesting.  Not sure how to make further progress without a lot of
work.

			regards, tom lane