Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group