On 06/03/2009 06:42 PM, Tom Lane wrote:
Andres Freund<and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
