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

From David Rowley
Subject Re: Marginal performance improvement: replace bms_first_member loops
Date
Msg-id CAApHDvpsPXzULsOi7YunTnqhbwZQmv3yDjV5ZbPe2FsX1t2DcQ@mail.gmail.com
Whole thread Raw
In response to Re: Marginal performance improvement: replace bms_first_member loops  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Nov 29, 2014 at 8:18 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
David Rowley <dgrowleyml@gmail.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:

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
  

pgsql-hackers by date:

Previous
From: Adam Brightwell
Date:
Subject: Re: Role Attribute Bitmask Catalog Representation
Next
From: Michael Paquier
Date:
Subject: New error code to track unsupported contexts