User-Agent: Microsoft-Entourage/11.2.5.060620
Date: Fri, 28 Jul 2006 14:43:23 -0700
Subject: Re: On-disk bitmap index patch
From: "Luke Lonergan" <llonergan@greenplum.com>
To: "Bruce Momjian" <bruce@momjian.us>,
	"Tom Lane" <tgl@sss.pgh.pa.us>
cc: "Dann Corbit" <DCorbit@connx.com>, "Jim C. Nasby" <jnasby@pervasive.com>,
	"Jie Zhang" <jzhang@greenplum.com>,
	"Mark Kirkwood" <markir@paradise.net.nz>,
	"Josh Berkus" <josh@agliodbs.com>, "Gavin Sherry" <swm@linuxworld.com.au>,
	pgsql-hackers@postgresql.org
Message-ID: <C0EFD30B.2B307%llonergan@greenplum.com>
Thread-Topic: [HACKERS] On-disk bitmap index patch
Thread-Index: Acayjtl0GEa+7h6CEdu8sgAWy4o9DA==
In-Reply-To: <200607282025.k6SKPNB08324@momjian.us>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce,

On 7/28/06 1:25 PM, "Bruce Momjian" <bruce@momjian.us> wrote:

> What we don't want to happen is for us to release bitmapped indexes, and
> find out later that btree is better in all cases.  Then we have to tell
> people not to use bitmapped indexes until we fix it in the next major
> releasse.  FYI, that is  basically where we are right now with hash
> indexes.

On this thread people have presented results that show clear and irrefutable
evidence that there are use cases where bitmap indexes outperform Btree for
many datatypes on realistic problems, including the TPC-H benchmark.

In many cases the bitmap indexes outperform BTREE by a factor of 50 and are
a tiny fraction of the size and also take dramatically less time to build.

Of the cases presented, we need to have someone specifically address them
and point out why they aren't proof of bitmap index performance.  So far
this has not been done, rather there are some unsupported opinions about
other cases that might be problematic.

- Luke