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

David Rowley <dgrowleyml@gmail.com> writes:
> I have to say I don't really like the modifying of the loop iterator that's
> going on here:

> col = -1;
> while ((col = bms_next_member(rte->modifiedCols, col)) >= 0)
> {
>   col += FirstLowInvalidHeapAttributeNumber;
>   /* do stuff */
>   col -= FirstLowInvalidHeapAttributeNumber;
> }

> Some other code is doing this:

> col = -1;
> while ((col = bms_next_member(cols, col)) >= 0)
> {
>   /* bit numbers are offset by FirstLowInvalidHeapAttributeNumber */
>   AttrNumber attno = col + FirstLowInvalidHeapAttributeNumber;

> Which seems less prone to future breakage and possibly slightly less cycles.

Yeah, I'd come to the same conclusion while thinking about it in the
shower this morning ...

> A while back when I was benchmarking the planner time during my trials with
> anti/semi join removals, I wrote a patch to change the usage pattern for
> cases such as:
> ...
> This knocked between 4 and 22% off of the time the planner spent in the join
> removals path.

Really!?  I've never seen either of those functions show up all that high
in profiles.  Can you share the test case you were measuring?
        regards, tom lane