David Rowley <david.row...@2ndquadrant.com> writes: > On Mon, 22 Jul 2019 at 02:45, Tom Lane <t...@sss.pgh.pa.us> wrote: >> One small question is whether it loses if most of the subplans >> are present in the bitmap. I imagine that would be close enough >> to break-even, but it might be worth trying to test to be sure.
> ... > -- Test 2 (all matching subplans (8192 of them)) -- > Master version: > Time: 14825.304 ms (00:14.825) > Time: 14701.601 ms (00:14.702) > Time: 14650.969 ms (00:14.651) > Patched version: > Time: 44551.811 ms (00:44.552) > Time: 44357.915 ms (00:44.358) > Time: 43454.958 ms (00:43.455) > So the bms_next_member() loop is slower when the bitmapset is fully > populated with all subplans, but way faster when there's just 1 > member. Interesting. I wonder if bms_next_member() could be made any quicker? Still, I agree that this is negligible compared to the actual work needed per live subplan, and the fact that the cost scales per live subplan is a good thing. So no objection to this patch, but a mental note to take another look at bms_next_member() someday. regards, tom lane