Re: plans for bitmap indexes?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Zeugswetter Andreas DAZ SD" <ZeugswetterA(at)spardat(dot)at>
Cc: josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, "Chris Browne" <cbbrowne(at)acm(dot)org>
Subject: Re: plans for bitmap indexes?
Date: 2004-10-13 14:19:50
Message-ID: 14200.1097677190@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Zeugswetter Andreas DAZ SD" <ZeugswetterA(at)spardat(dot)at> writes:
> Workable examples for useful partitioned indexes, that help here are:

> create index people_male_ix on people (city) where gender = 'male';
> create index people_gay_ix on people (city) where orientation = 'gay';
> create index people_male_gay_ix on people (city) where gender = 'male' and orientation = 'gay';

> Note, that the indexed column differs from the partitioning clause.
> Note also, that the last index will perform way better than a combo of bitmap indexes.

This is definitely a useful technique in some cases, but it's got its
limits. You have to have only a fairly small number of interesting
conditions (else the number of indexes gets out of hand) and those
conditions have to be spelled out explicitly in the query. That is,
the last index will indeed work for
SELECT * FROM people WHERE orientation = 'gay'
AND gender = 'male' AND city = 'San Francisco';
but it will not work for
SELECT * FROM people WHERE orientation = $1
AND gender = $2 AND city = $3;
which is the sort of thing that the planner is increasingly going to
have to deal with.

Combining bitmaps at runtime is certainly somewhat more expensive to
execute, but it can deal with cases where the specific values being
searched for are not known until runtime.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Reini Urban 2004-10-13 14:33:23 Re: more dirmod CYGWIN
Previous Message Reini Urban 2004-10-13 12:28:44 Re: more dirmod CYGWIN