Re: On-disk bitmap index patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Dann Corbit" <DCorbit(at)connx(dot)com>
Cc: "Luke Lonergan" <llonergan(at)greenplum(dot)com>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, "Jie Zhang" <jzhang(at)greenplum(dot)com>, "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz>, "Josh Berkus" <josh(at)agliodbs(dot)com>, "Gavin Sherry" <swm(at)linuxworld(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: On-disk bitmap index patch
Date: 2006-07-28 20:18:53
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

"Dann Corbit" <DCorbit(at)connx(dot)com> writes:
> Others have looked into the usefulness of bitmap indexes. Here is what
> they found:

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.


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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-07-28 20:25:23 Re: On-disk bitmap index patch
Previous Message Stefan Kaltenbrunner 2006-07-28 20:13:06 Re: [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]