|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|
|Views:||Raw Message | Whole Thread | Download mbox|
"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
|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]|