Re: On-disk bitmap index patch

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: On-disk bitmap index patch
Дата
Msg-id 17917.1153847188@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: On-disk bitmap index patch  ("Luke Lonergan" <LLonergan@greenplum.com>)
Ответы Re: On-disk bitmap index patch  (Hannu Krosing <hannu@skype.net>)
Re: On-disk bitmap index patch  ("Ayush Parashar" <aparashar@greenplum.com>)
Список pgsql-hackers
"Luke Lonergan" <LLonergan@greenplum.com> writes:
> I think we do know, have you reviewed the results in the briefing?

I find those results moderately unconvincing, primarily because they
are based on choosing the least efficient possible data representation
(viz char(n)), and thus the btree indexes suffer severe and quite
artificial bloat.  A database schema chosen with even minimal attention
to PG-specific tuning would probably have btree indexes half the size.
That wouldn't completely eliminate the performance differential shown,
but it would bring it down into the ballpark where you have to question
whether it makes sense to support another index AM.

The reason I have such high sales resistance is that we've carried the
hash and rtree AMs for years, hoping that someone would do the work to
make them actually worth using, with little result.  I don't want any
more second-class-citizen index AMs, and that's why I'm questioning
what the scope of applicability of bitmap indexes really is.  They need
to be popular enough that people will be motivated to work on them,
or they shouldn't be in core.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Chris Browne
Дата:
Сообщение: Re: Help! - Slony-I - saving/setting/restoring GUC
Следующее
От: "Hiroshi Saito"
Дата:
Сообщение: Re: [PATCHES] Patch for VS.Net 2005's strxfrm() bug