On 2017/11/06 21:52, David Rowley wrote: > On 6 November 2017 at 23:01, Amit Langote <langote_amit...@lab.ntt.co.jp> > wrote: >> OK, I have gotten rid of the min/max partition index interface and instead >> adopted the bms_add_range() approach by including your patch to add the >> same in the patch set (which is now 0002 in the whole set). I have to >> admit that it's simpler to understand the new code with just Bitmapsets to >> look at, but I'm still a bit concerned about materializing the whole set >> right within partition.c, although we can perhaps optimize it later. > > Thanks for making that change. The code looks much more simple now. > > For performance, if you're worried about a very large number of > partitions, then I think you're better off using bms_next_member() > rather than bms_first_member(), (likely this applies globally, but you > don't need to worry about those). > > The problem with bms_first_member is that it must always loop over the > 0 words before it finds any bits set for each call, whereas > bms_next_member will start on the word it was last called for. There > will likely be a pretty big performance difference between the two > when processing a large Bitmapset.
Ah, thanks for the explanation. I will change it to bms_next_member() in the next version. >> Attached updated set of patches, including the fix to make the new pruning >> code handle Boolean partitioning. > > Thanks. I'll look over it all again starting my Tuesday morning. (UTC+13) Thank you. Regards, Amit -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers