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. > 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) -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
