Subject: Re: On-disk bitmap index patch
From: Hannu Krosing <hannu@skype.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Gavin Sherry <swm@linuxworld.com.au>,
	Jie Zhang <jzhang@greenplum.com>, pgsql-hackers@postgresql.org,
	Luke Lonergan <LLonergan@greenplum.com>
In-Reply-To: <28750.1153700718@sss.pgh.pa.us>
References: <C0E1CD9D.8DC0%jzhang@greenplum.com>
	<Pine.LNX.4.58.0607240720180.19004@linuxworld.com.au>
	<28525.1153698215@sss.pgh.pa.us>
	<Pine.LNX.4.58.0607240952250.19854@linuxworld.com.au>
	<28750.1153700718@sss.pgh.pa.us>
Content-Type: text/plain; charset=utf-8
Date: Mon, 24 Jul 2006 16:59:35 +0300
Message-Id: <1153749575.2909.3.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit

Ühel kenal päeval, P, 2006-07-23 kell 20:25, kirjutas Tom Lane:
> Gavin Sherry <swm@linuxworld.com.au> writes:
> > On Sun, 23 Jul 2006, Tom Lane wrote:
> >> However, the main problem I've got with this is that a new index AM is a
> >> pretty large burden, and no one's made the slightest effort to sell
> >> pghackers on taking this on.
> 
> > For low cardinality sets, bitmaps greatly out perform btree.
> 
> If the column is sufficiently low cardinality, you might as well just do
> a seqscan --- you'll be hitting most of the heap's pages anyway.  I'm
> still waiting to be convinced that there's a sweet spot wide enough to
> justify supporting another index AM.  (I'm also wondering whether this
> doesn't overlap the use-case for GIN.)

IIRC they quoted the cardinality of 10000 as something that is still
faster than btree for several usecases.

And also for AND-s of several indexes, where indexes are BIG, your btree
indexes may be almost as big as tables but the resulting set of pages is
small.

-- 
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com