Re: Implementing Bitmap Indexes - Mailing list pgsql-hackers

From Mike Rylander
Subject Re: Implementing Bitmap Indexes
Date
Msg-id b918cf3d05012910464e10278b@mail.gmail.com
Whole thread Raw
In response to Re: Implementing Bitmap Indexes  ("Victor Y. Yegorov" <viy@mits.lv>)
Responses Re: Implementing Bitmap Indexes
Re: Implementing Bitmap Indexes
Re: Implementing Bitmap Indexes
List pgsql-hackers
On Sat, 29 Jan 2005 19:41:20 +0200, Victor Y. Yegorov <viy@mits.lv> wrote:
> * Pawe� Niewiadomski <new@foo-baz.com> [29.01.2005 17:45]:
> > > I'd like to implement bitmap indexes and want your comments. Here is
> > > an essence of what I've found regarding bitmaps for the last month.
> >
> > Do you think it would be possible to work on it as a team?
>
> Yes, why not.
>
> But everything depends on the community, may bitmaps will be realized as a
> contrib or pgfoundry module. The only thing --- I don't know, if that is
> possible for indexes.

For on-disk bitmap indexes, yes.  I don't see any reason this couldn't
be done with GiST, perhaps even as a generalization of the index stuff
in the int_array contrib module.  But the bitmaps that Tom as been
advocating, the ones used to join two index scans, will require a new
planner Op.

As a side note, wouldn't the in-memory bitmaps pretty much kill the
need for multicolumn indexes?  It seems that they would be able to
join index scans on the same table, and then there would be no need
for industrial strength cross-column correlation stats.  The planner
would be able to choose a multi index scan based on multiple single
column stat entries and completely sidestep the need for precalculated
cross-column correlations.  Am I getting that right?

--
Mike Rylander
mrylander@gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Security bugs in tsearch2
Next
From: Dawid Kuroczko
Date:
Subject: Re: Implementing Bitmap Indexes