Nathan Bossart <nathandboss...@gmail.com> writes: > 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().
The zero-fill to reinitialize the filter probably costs a good deal all by itself, considering we're talking about at least a megabyte. Maybe a better idea is to not enable the filter till we're dealing with at least 1000 or so entries in roles_list, though obviously that will complicate the logic. + if (bloom_lacks_element(bf, (unsigned char *) &otherid, sizeof(Oid))) + roles_list = lappend_oid(roles_list, otherid); + else + roles_list = list_append_unique_oid(roles_list, otherid); + bloom_add_element(bf, (unsigned char *) &otherid, sizeof(Oid)); Hmm, I was imagining something more like if (bloom_lacks_element(bf, (unsigned char *) &otherid, sizeof(Oid)) || !list_member_oid(roles_list, otherid)) { roles_list = lappend_oid(roles_list, otherid); bloom_add_element(bf, (unsigned char *) &otherid, sizeof(Oid)); } to avoid duplicate bloom_add_element calls. Probably wouldn't move the needle much in this specific test case, but this formulation would simplify letting the filter kick in later. Very roughly, if ((bf && bloom_lacks_element(bf, (unsigned char *) &otherid, sizeof(Oid))) || !list_member_oid(roles_list, otherid)) { if (bf == NULL && list_length(roles_list) > 1000) { ... create bf and populate with existing list entries } roles_list = lappend_oid(roles_list, otherid); if (bf) bloom_add_element(bf, (unsigned char *) &otherid, sizeof(Oid)); } regards, tom lane