Re: Plan time Improvement - 64bit bitmapset

On 06/03/2009 06:42 PM, Tom Lane wrote:
> Andres Freund<andres@anarazel.de>  writes:
>> On 06/03/2009 06:21 PM, Tom Lane wrote:
>>> I find this *really* hard to believe, because I've never seen the bitmap
>>> support operations show up noticeably at all in profiles.  What sort of
>>> queries are you testing?
>
>> Many left joins from one base relation to additional dimensions. All the
>> dimensions are relatively complex views consisting out of multiple joins
>> or subselects.
>> Some correlated subqueries and some [NOT] EXISTS() are also included in
>> some of the queries.
> Hmmm, could you provide a complete test case?  I'm thinking the behavior
> might indicate some other performance issue, ie an unreasonable number
> of bitmapset calls in some particular planning path.
Uh. I will try, but probably it is not easy. (Once more a 
datawarehouse-ish example database would be useful).

The graph linked in the former email includes all callers with relevant 
amount of calls (generate_join_implied_equalities, join_is_legal, 
have_join_order_restriction are in this order the by far most costly).

I put up the raw profile data at:
http://anarazel.de/pg/32bit_bitmaps.out.gz
http://anarazel.de/pg/64bit_bitmaps.out.gz
As I said, unfortunately only kcachegrind seems to be able to load the 
data - it is included in most linux distros though.

> There used to be some performance issues in this area back when we
> represented sets of relids as integer Lists :-(, but the change to
> bitmap sets pretty much stomped that.  I'm just really surprised that
> there would be anything measurable from changing the word width.
Well, the number of memory accesses is halved and I think that bitwise 
NOT and AND take the same amount of cycles whether they are operating on 
32 or 64bit. That would explain some difference.

Andres