| From: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Jie Zhang <jzhang(at)greenplum(dot)com>, Hannu Krosing <hannu(at)skype(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Luke Lonergan <LLonergan(at)greenplum(dot)com> |
| Subject: | Re: On-disk bitmap index patch |
| Date: | 2006-07-25 01:51:05 |
| Message-ID: | Pine.LNX.4.58.0607251149250.445@linuxworld.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 24 Jul 2006, Bruce Momjian wrote:
> 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.
WHERE a = 1 and b = 2
a = 1 may be 5% of the table and b = 2 may be 5% of the table but their
intersection may be .001%.
Luke: the URL you sent to the bitmap slides was internal to Greenplum.
Would you be able to put them on a public site?
Thanks,
Gavin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | mark | 2006-07-25 01:58:05 | Re: On-disk bitmap index patch |
| Previous Message | Bruce Momjian | 2006-07-25 01:49:33 | Re: pgstattuple extension for indexes |