From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, alex work <alexwork033(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs |
Date: | 2024-03-22 01:52:51 |
Message-ID: | 20240322015251.GA2193900@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Thu, Mar 21, 2024 at 08:03:32PM -0500, Nathan Bossart wrote:
> On Thu, Mar 21, 2024 at 08:59:54PM -0400, Tom Lane wrote:
>> However ... I just remembered that we have a Bloom filter implementation
>> in core now (src/backend/lib/bloomfilter.c). How about using that
>> to quickly reject (hopefully) most role OIDs, and only do the
>> list_member_oid check if the filter passes?
>
> Seems worth a try. I've been looking for an excuse to use that...
The Bloom filter appears to help a bit, although it regresses the
create-roles.sql portion of the test. I'm assuming that's thanks to all
the extra pallocs and pfrees, which are probably avoidable if we store the
filter in a long-lived context and just clear it at the beginning of each
call to roles_is_member_of().
HEAD hash hash+bloom
create 2.02 2.06 2.92
grant 4.63 0.27 0.08
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Attachment | Content-Type | Size |
---|---|---|
bloom.patch | text/x-diff | 2.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | alex work | 2024-03-22 02:02:57 | Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs |
Previous Message | Nathan Bossart | 2024-03-22 01:03:32 | Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs |
From | Date | Subject | |
---|---|---|---|
Next Message | alex work | 2024-03-22 02:02:57 | Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs |
Previous Message | Vik Fearing | 2024-03-22 01:12:48 | Re: Catalog domain not-null constraints |