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

From Tom Lane
Subject Re: Marginal performance improvement: replace bms_first_member loops
Date
Msg-id 9024.1417187316@sss.pgh.pa.us
Whole thread Raw
In response to Re: Marginal performance improvement: replace bms_first_member loops  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-hackers
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> 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.

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

Excellent point!  Thanks for noticing that.

> 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.

Yeah, I had considered whether to do that; instead of just prevbit++
it would need to be something likeprevbit = (prevbit < 0) ? 0 : prevbit + 1;
This would add one test-and-branch, and moreover one that would be
hard to predict correctly (given that most of our bitmapsets don't
have very many members).  So it seems pretty expensive.  Probably
a more explicit warning in the header comment is good enough; or
we could put in an Assert().
        regards, tom lane



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: The problems of PQhost()
Next
From: Tom Lane
Date:
Subject: Re: Marginal performance improvement: replace bms_first_member loops