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
Re: On-disk bitmap index patch Re: On-disk bitmap index patch Re: On-disk bitmap index patch |
Список | 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 по дате отправления: