Re: On-disk bitmap index patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: On-disk bitmap index patch
Date
Msg-id 809.1154117933@sss.pgh.pa.us
Whole thread Raw
In response to Re: On-disk bitmap index patch  ("Dann Corbit" <DCorbit@connx.com>)
Responses Re: On-disk bitmap index patch  (Bruce Momjian <bruce@momjian.us>)
Re: On-disk bitmap index patch  (Andrew Dunstan <andrew@dunslane.net>)
Re: On-disk bitmap index patch  (Hannu Krosing <hannu@skype.net>)
Re: On-disk bitmap index patch  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
List pgsql-hackers
"Dann Corbit" <DCorbit@connx.com> writes:
> Others have looked into the usefulness of bitmap indexes.  Here is what
> they found:
> http://www.oracle.com/technology/pub/articles/sharma_indexes.html

I like this guy's style of argument: he admits a bitmap index on a
unique column will be much bigger than a btree, and then airily
dismisses it as not a problem.  Not real convincing.

> http://citeseer.ist.psu.edu/stockinger02bitmap.html

Both of these pages say up front that they are considering read-only
data.  So one of the questions that has to be answered (and the
submitters have been entirely mum about) is exactly how bad is the
update performance?  If it's really awful that's going to constrain
the use cases quite a lot, whereas merely "a bit slower than btree"
wouldn't be such a problem.

In any case, arguing that other DBs find it's a win will cut no ice
with me.  See adjacent discussion about hash indexes --- those *ought*
to be a win, but they aren't in Postgres, for reasons that are still
guesses.  The translation gap between other DBs' experience and ours
can be large.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]
Next
From: Bruce Momjian
Date:
Subject: Re: On-disk bitmap index patch