Nathan Bossart <nathandboss...@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