Re: On-disk bitmap index patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Luke Lonergan" <LLonergan(at)greenplum(dot)com>
Cc: mark(at)mark(dot)mielke(dot)cc, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Jie Zhang" <jzhang(at)greenplum(dot)com>, "Hannu Krosing" <hannu(at)skype(dot)net>, "Gavin Sherry" <swm(at)linuxworld(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: On-disk bitmap index patch
Date: 2006-07-25 17:06:28
Message-ID: 17917.1153847188@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Luke Lonergan" <LLonergan(at)greenplum(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Saito 2006-07-25 17:12:31 Re: [HACKERS] Patch for VS.Net 2005's strxfrm() bug
Previous Message Jim Nasby 2006-07-25 16:57:49 Re: Freezing tuples on pages dirtied by vacuum