From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: pgsql-hackers@lists.postgresql.org, 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: <20240322145532.GA2346110@nathanxps13>
References: <CAGvXd3OSMbJQwOSc-Tq-Ro1CAz=vggErdSG7pv2s6vmmTOLJSg@mail.gmail.com> <341186.1711037256@sss.pgh.pa.us> <619340.1711050134@sss.pgh.pa.us> <642442.1711053105@sss.pgh.pa.us> <20240321204012.GA1992418@nathanxps13> <20240322005139.GA2060816@nathanxps13> <806361.1711069194@sss.pgh.pa.us> <20240322144739.GA2321246@nathanxps13> <20240322145532.GA2346110@nathanxps13>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Fri, 22 Mar 2024 09:55:32 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <907784.1711121266.1@sss.pgh.pa.us>
Date: Fri, 22 Mar 2024 11:27:46 -0400
Message-ID: <907785.1711121266@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/907785.1711121266%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> On Fri, Mar 22, 2024 at 09:47:39AM -0500, Nathan Bossart wrote:
>>         hash     hash+simd hash+simd+bloom
>> create  1.27     1.27      1.28
>> grant   0.18     0.11      0.03

> For just hash+bloom, I'm seeing 1.29 and 0.04.

Yeah, that's about what I'd expect: hash+bloom ought to remove
most (not quite all) of the opportunity for simd to shine, because
the bloom filter should eliminate most of the list_member_oid calls.

Possibly we could fix that small regression in the create phase
with more careful tuning of the magic constants in the bloom
logic?  Although I'd kind of expect that the create step doesn't
ever invoke the bloom filter, else it would have been showing a
performance problem before; so this might not be a good test case
for helping us tune those.

I think remaining questions are:

* Is there any case where the new hash catcache logic could lose
measurably?  I kind of doubt it, because we were already computing
the hash value for list searches; so basically the only overhead
is one more palloc per cache during the first list search.  (If
you accumulate enough lists to cause a rehash, you're almost
surely well into winning territory.)

* Same question for the bloom logic, but here I think it's mostly
a matter of tuning those constants.

* Do we want to risk back-patching any of this, to fix the performance
regression in v16?  I think that the OP's situation is a pretty
narrow one, but maybe he's not the only person who managed to dodge
roles_is_member_of's performance issues in most other cases.

			regards, tom lane