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
