Re: Switching to 64-bit Bitmapsets

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Switching to 64-bit Bitmapsets
Date: 2018-12-20 17:26:51
Message-ID: 6208.1545326811@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> On Thu, 20 Dec 2018 at 17:50, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Hm, are you thinking of making BITS_PER_BITMAPWORD match sizeof(Pointer)
>> or something like that? That seems like a good compromise from here.

> Yeah, something along those lines. I've implemented that in the attached.

Pushed with some fiddling with the comment.

I wasn't excited about the test case you offered --- on HEAD, it pretty
much all devolves to file access operations (probably, checking the
current length of all the child relations). Instead I experimented
with an old test case I had for a complex-to-plan query, and got these
results:

HEAD, asserts off:

pgbench reports:
latency average = 11704.992 ms
tps = 0.085434 (including connections establishing)
tps = 0.085437 (excluding connections establishing)

Top hits according to perf:
+ 65.42% 65.16% 158499 postmaster postgres [.] match_eclasses_to_foreign_key_col
+ 6.85% 6.82% 16634 postmaster postgres [.] bms_overlap
+ 6.25% 6.22% 15173 postmaster postgres [.] generate_join_implied_equalities_for_ecs
+ 3.91% 3.88% 9465 postmaster postgres [.] make_canonical_pathkey
+ 3.04% 3.01% 7351 postmaster postgres [.] have_relevant_eclass_joinclause
+ 2.06% 2.05% 4992 postmaster postgres [.] bms_is_subset
+ 1.19% 1.18% 2887 postmaster postgres [.] equal
+ 0.95% 0.95% 2309 postmaster postgres [.] get_eclass_for_sort_expr
+ 0.90% 0.90% 2189 postmaster postgres [.] add_paths_to_joinrel

With patch:

latency average = 10741.595 ms
tps = 0.093096 (including connections establishing)
tps = 0.093099 (excluding connections establishing)

+ 69.03% 68.76% 178278 postmaster postgres [.] match_eclasses_to_foreign_key_col
+ 5.85% 5.82% 15138 postmaster postgres [.] generate_join_implied_equalities_for_ecs
+ 4.58% 4.55% 11842 postmaster postgres [.] bms_overlap
+ 4.38% 4.36% 11338 postmaster postgres [.] make_canonical_pathkey
+ 2.77% 2.75% 7155 postmaster postgres [.] have_relevant_eclass_joinclause
+ 1.30% 1.29% 3364 postmaster postgres [.] equal
+ 1.26% 1.25% 3261 postmaster postgres [.] bms_is_subset
+ 1.06% 1.05% 2722 postmaster postgres [.] get_eclass_for_sort_expr
+ 0.70% 0.70% 1813 postmaster postgres [.] add_paths_to_joinrel

Ignoring the, um, elephant in the room, this shows a pretty clear win
for the performance of bms_overlap and bms_is_subset, confirming
the thesis that this change is worthwhile.

I'll start a separate thread about match_eclasses_to_foreign_key_col.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-12-20 17:28:31 Re: lock level for DETACH PARTITION looks sketchy
Previous Message Alexey Bashtanov 2018-12-20 16:59:29 Re: A case for UPDATE DISTINCT attribute