On Thu, Aug 10, 2017 at 1:39 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On my computer it took ~1.5 seconds to plan a 1000 partition join, > ~7.1 seconds to plan a 2000 partition join, and ~50 seconds to plan a > 4000 partition join. I poked around in a profiler a bit and saw that > for the 2000 partition case I spent almost half the time in > create_plan->...->prepare_sort_from_pathkeys->find_ec_member_for_tle, > and about half of that was in bms_is_subset. The other half the time > was in query_planner->make_one_rel which spent 2/3 of its time in > set_rel_size->add_child_rel_equivalences->bms_overlap and the other > 1/3 in standard_join_search.
Ashutosh asked me how I did that. Please see attached. I was explaining simple joins like SELECT * FROM foofoo JOIN barbar USING (a, b). Here also is the experimental hack I tried when I saw bitmapset.c eating my CPU. -- Thomas Munro http://www.enterprisedb.com
bitmapset-track-leading-empty-space.patch
Description: Binary data
make-partitions.sh
Description: Bourne shell script
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
