Re: On-disk bitmap index patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: On-disk bitmap index patch
Date
Msg-id 17917.1153847188@sss.pgh.pa.us
Whole thread Raw
In response to Re: On-disk bitmap index patch  ("Luke Lonergan" <LLonergan@greenplum.com>)
Responses Re: On-disk bitmap index patch  (Hannu Krosing <hannu@skype.net>)
Re: On-disk bitmap index patch  ("Ayush Parashar" <aparashar@greenplum.com>)
List 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 by date:

Previous
From: Chris Browne
Date:
Subject: Re: Help! - Slony-I - saving/setting/restoring GUC
Next
From: "Hiroshi Saito"
Date:
Subject: Re: [PATCHES] Patch for VS.Net 2005's strxfrm() bug