Re: Marginal performance improvement: replace bms_first_member loops

On Sat, Nov 29, 2014 at 8:18 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> > 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:
>
> > if (bms_membership(a) != BMS_SINGLETON)
> > return; /* nothing to do */
> > singleton = bms_singleton_member(a);
> > ...
>
> > Into:
>
> > if (!bms_get_singleton(a, &singleton))
> > return; /* nothing to do */
> > ...
>
> > Which means 1 function call and loop over the bitmapset, rather than 2
> > function
> > calls and 2 loops over the set when the set is a singleton.
>
> I went ahead and committed this with some cosmetic adjustments.
>

Thank you!

> I'm not sure about there being any performance win in existing use-cases,
> but it seems worth doing on notational grounds anyway.
>
>
My original benchmarks for this were based on the semi/anti join patch I
was working on at the time

Benchmarks here:
http://www.postgresql.org/message-id/CAApHDvo21-b+PU=sC9B1QiEG3YL4T919i4WjZfnfP6UPXS9nZg@mail.gmail.com

Though the existing left join removal code should see similar speed ups,
albeit the time spent in the join removal code path did only happen to be
between 0.02 and 0.2% of total planning time with my test cases.

Regards

David Rowley