Nathan Bossart <nathandboss...@gmail.com> writes: > On Tue, Mar 26, 2024 at 02:16:03PM -0400, Tom Lane wrote: >> ... I'm not sold on your "ROLES_LIST_BLOOM_THRESHOLD * 10" >> value. Maybe it doesn't matter though.
> Yeah, I wasn't sure how much to worry about this. I figured that we might > as well set it to a reasonable estimate based on the description of the > parameter. This description claims that the filter should work well if > this is off by a factor of 5 or more, and 50x the threshold sounded like it > ought to be good enough for anyone, so that's how I landed on 10x. But as > you point out, this value will be disregarded altogether, and it will > continue to be ignored unless the filter implementation changes, which > seems unlikely. If you have a different value in mind that you would > rather use, I'm fine with changing it. No, I have no better idea. As you say, we should try to provide some semi-reasonable number in case bloom_create ever starts paying attention, and this one seems fine. >> I do not like, even a little bit, your use of a static variable to >> hold the bloom filter pointer. > Ah, yes, that's no good. I fixed this in the new version. My one remaining suggestion is that this comment isn't very precise about what's happening: * If there is a previously-created Bloom filter, use it to determine * whether the role is missing from the list. Otherwise, do an ordinary * linear search through the existing role list. Maybe more like * If there is a previously-created Bloom filter, use it to try to * determine whether the role is missing from the list. If it * says yes, that's a hard fact and we can go ahead and add the * role. If it says no, that's only probabilistic and we'd better * search the list. Without a filter, we must always do an ordinary * linear search through the existing list. LGTM other than that nit. regards, tom lane