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

From Bruce Momjian
Subject Re: On-disk bitmap index patch
Date
Msg-id 200607250104.k6P14St25388@momjian.us
Whole thread Raw
In response to Re: On-disk bitmap index patch  ("Jie Zhang" <jzhang@greenplum.com>)
Responses Re: On-disk bitmap index patch  ("Jie Zhang" <jzhang@greenplum.com>)
Re: On-disk bitmap index patch  (Gavin Sherry <swm@linuxworld.com.au>)
Re: On-disk bitmap index patch  (mark@mark.mielke.cc)
List pgsql-hackers
Jie Zhang wrote:
> > 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.
> 
> Yeah, Hannu points it out very well -- the bitmap index works very well when
> columns have low cardinalities and AND operations will produce small number
> of results.

What operations on columns of low cardinality produce a small number of
results?  That seems contradictory.

> Also, the bitmap index is very small in low cardinality cases, where the
> btree tends to take up at least 10 times more space.

Also, are adding/changing rows is more expensive with bitmaps than
btrees?

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: pg_dump: add option to ignore TABLE DATA for failed TABLE object creation
Next
From: David Fetter
Date:
Subject: Re: Units in postgresql.conf -- How to report?