Re: On-disk bitmap index patch

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: On-disk bitmap index patch
Дата
Msg-id 809.1154117933@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: On-disk bitmap index patch  ("Dann Corbit" <DCorbit@connx.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Stefan Kaltenbrunner
Дата:
Сообщение: Re: [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: On-disk bitmap index patch