Re: plans for bitmap indexes?

From: Greg Stark <gsstark(at)mit(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: plans for bitmap indexes?
Date: 2004-10-12 21:09:20
Message-ID: 87wtxvzlrz.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Josh Berkus <josh(at)agliodbs(dot)com> writes:

> SELECT * FROM people WHERE orientation = 'gay' AND gender = 'male' AND city =
> 'San Francisco';

There are actually two TODOs here.

1) a "bitmap scan" that would be usable with any type of index. The tuple
locations can be read in for each criteria and sorted by location and built
into bitmaps. The results can be combined using bitmap operations and the
tuples scanned in physical order.

2) A persistent bitmap index that would enable skipping the first step of the
above.

In the case if all the columns were btree indexes it might still make sense to
scan through all the indexes and combine the results before reading in the
actual tuples. Especially if the tuples are very wide and each column
individually very unselective, but the combination very selective.

However it would work even better if gender and orientation could be stored on
disk in a bitmap representation. They're very low cardinality and could be
stored quite compactly. The result would read the data faster, skip the sort,
and be able to start returning tuples even before it finished reading the
entire index.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-10-12 21:10:42 Re: plans for bitmap indexes?
Previous Message Tom Lane 2004-10-12 21:02:43 Re: Hypothetical Indexes