On Tue, 3 Mar 2026 at 15:55, Thomas Munro <[email protected]> wrote: > I played around with the idea of supporting "immediate" Bitmapset > values that skip allocation and pointer chasing overheads and live in > registers, as long as they fit. Prototype-grade patch attached.
> I'm interested to hear whether people think this sort of thing is > worth pursuing, how much of a problem Bitmapset manipulation really > is, whether it's worth hacking on the Node system to achieve that, etc > etc. It would be interesting to know if you've seen any sign that this would result in any performance improvements? It's going to be much easier to justify adding complexity when there's a demonstration of some sort of performance gain from doing so. There was some testing in [1] that showed that the planner can be quite sensitive to Bitmapset performance in certain cases. IIRC, the 2x speed up in there was due to the bms_is_subset short-circuit that was added in that patch for "/* 'a' can't be a subset of 'b' if it contains more words */". Prior to that change, a Bitmapset could have trailing zero words. I think primarily those tests focus on Bitmapsets with multiple words, so it might not be the test for your case. I'd would be good to check it doesn't make it too much slower, however. > Another superficial aspect is that it feels like some > common operations are obvious candidates for inlining of at least > their happy paths. I was wondering this too. I think the gains would be much more if you could avoid the pointer dereference AND the function call overhead. The more simple ones are maybe worth a look at to consider. Most times I see bms_is_member(), I consider if it would be worth inlining. It's just that elog(ERROR) that puts me off. I do wonder if we should be returning false for < 0 and maybe convert the elog to an Assert. bms_overlap(), bms_equal() and bms_is_subset() are likely good candidates. They're heavily used during the planner's join search by join_is_legal(). make_rels_by_clause_joins() uses bms_overlap(). For benchmarking, you might need to carefully craft a query that is fairly restricted in terms of join order so that not too many Paths are generated, which could well drown out any gains you might get. David [1] https://www.postgresql.org/message-id/caj2pmkyckhfbd_omusvyhysqu0-j9t6nz0pl6pwbzsucohw...@mail.gmail.com
