Re: Marginal performance improvement: replace bms_first_member loops - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: Marginal performance improvement: replace bms_first_member loops
Date
Msg-id CAEZATCVZ_4tcpGPb1h=2NUzXhK2z8mWPRbsQyMWa4Y3Q=fzVWg@mail.gmail.com
Whole thread Raw
In response to Marginal performance improvement: replace bms_first_member loops  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Marginal performance improvement: replace bms_first_member loops  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 27 November 2014 at 19:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The attached proposed patch adds bms_next_member() and replaces
> bms_first_member() calls where it seemed to make sense.  I've had a
> hard time measuring much speed difference for this patch in isolation,
> but in principle it should be less code and less cycles.  It also seems
> safer and more natural to not use destructive looping techniques.
>

+1. I had a similar idea a while back but didn't have time to produce
a complete patch.

There is another micro-optimisation that you could make in
bms_next_member() -- it isn't necessary to do
   w = RIGHTMOST_ONE(w)

because unlike bms_next_member, w isn't being used to mask out the bit
retrieved, so any higher bits don't matter and the later use of
rightmost_one_pos[...] will pick out the required rightmost bit.

Should this function protect against large negative inputs? As it
stands, passing in a value of prevbit less than -1 would be
problematic. Maybe it's sufficient to say "don't do that" in the docs,
rather than waste more cycles checking.

Regards,
Dean



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Using pg_rewind for differential backup
Next
From: Ashutosh Bapat
Date:
Subject: Re: inherit support for foreign tables