Re: Making empty Bitmapsets always be NULL

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
Cc: Yuya Watari <watari(dot)yuya(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Making empty Bitmapsets always be NULL
Date: 2023-06-24 00:47:44
Message-ID: CAApHDvqb14dXuxw05i2rX66rP5mb6RGzRUVMYLruSb_EaAntJg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 24 Jun 2023 at 07:43, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
> I worked a bit more on the v4 version and made a new v6 version, with some changes.

> I can see some improvement, would you mind testing v6 and reporting back?

Please don't bother. I've already mentioned that I'm not going to
consider any changes here which are unrelated to changing the rule
that Bitmapsets no longer can have trailing zero words. I've already
said in [1] that if you have unrelated changes that you wish to pursue
in regards to Bitmapset, then please do so on another thread.

Also, FWIW, from glancing over it, your v6 patch introduces a bunch of
out-of-bounds memory access bugs and a few things are less efficient
than I'd made them. The number of bytes you're zeroing using memset in
bms_add_member() and bms_add_range() is wrong. bms_del_member() now
needlessly rechecks if a->words[wordnum] is 0. We already know it is 0
from the above check. You may have misunderstood the point of swapping
for loops for do/while loops? They're meant to save the needless loop
bounds check on the initial loop due to the knowledge that the
Bitmapset contains at least 1 word.

Additionally, it looks like you've made various places that loop over
the set and check for the "lastnonzero" less efficiently by adding an
additional surplus check. Depending on the CPU architecture, looping
backwards over arrays can be less efficient due to lack of hardware
prefetching when accessing memory in reverse order. It's not clear to
me why you think looping backwards is faster. I've no desire to
introduce code that needlessly performs more slowly depending on the
ability of the hardware prefetcher on the CPU architecture PostgreSQL
is running on.

Also, if you going to post benchmark results, they're not very
meaningful unless you can demonstrate what you actually tested. You've
mentioned nothing here to say what query-b.sql contains.

David

[1] https://postgr.es/m/CAApHDvo65DXFZcGJZ7pvXS75vUT+1-wSaP_kvefWGsns2y2vsg@mail.gmail.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2023-06-24 01:28:26 Re: psql: Add role's membership options to the \du+ command
Previous Message David Rowley 2023-06-24 00:33:46 Re: Stampede of the JIT compilers