Re: On-disk bitmap index patch

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: On-disk bitmap index patch
Дата
Msg-id
28750.1153700718@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
automatic system info tool? Andrew Dunstan <andrew@dunslane.net>
Re: automatic system info tool? Josh Berkus <josh@agliodbs.com>
Re: automatic system info tool? Peter Eisentraut <peter_e@gmx.net>
Re: automatic system info tool? Andrew Dunstan <andrew@dunslane.net>
Re: automatic system info tool? Martijn van Oosterhout <kleptog@svana.org>
Re: automatic system info tool? Andrew Dunstan <andrew@dunslane.net>
Re: automatic system info tool? Martijn van Oosterhout <kleptog@svana.org>
Re: automatic system info tool? "Bort, Paul" <pbort@tmwsystems.com>
Re: automatic system info tool? Martijn van Oosterhout <kleptog@svana.org>
Re: automatic system info tool? Steve Atkins <steve@blighty.com>
Re: automatic system info tool? "Zeugswetter Andreas DCP SD" <ZeugswetterA@spardat.at>
Re: automatic system info tool? "Bort, Paul" <pbort@tmwsystems.com>
Re: automatic system info tool? "Andrej Ricnik-Bay" <andrej.groups@gmail.com>
Re: automatic system info tool? Andrew Dunstan <andrew@dunslane.net>
Gavin Sherry  writes:
> On Sun, 23 Jul 2006, Tom Lane wrote:
>> However, the main problem I've got with this is that a new index AM is a
>> pretty large burden, and no one's made the slightest effort to sell
>> pghackers on taking this on.

> For low cardinality sets, bitmaps greatly out perform btree.

If the column is sufficiently low cardinality, you might as well just do
a seqscan --- you'll be hitting most of the heap's pages anyway.  I'm
still waiting to be convinced that there's a sweet spot wide enough to
justify supporting another index AM.  (I'm also wondering whether this
doesn't overlap the use-case for GIN.)
		regards, tom lane

В списке pgsql-hackers по дате отправления
От: Gavin Sherry
Дата:
Сообщение: Re: On-disk bitmap index patch
От: Luke Lonergan
Дата:
Сообщение: Re: On-disk bitmap index patch
FAQ