Re: plans for bitmap indexes?

From: "Zeugswetter Andreas DAZ SD" <ZeugswetterA(at)spardat(dot)at>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Cc: "Chris Browne" <cbbrowne(at)acm(dot)org>
Subject: Re: plans for bitmap indexes?
Date: 2004-10-14 08:09:43
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA40184D1E3@m0114.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> > create index people_male_gay_ix on people (city) where gender = 'male' and
> > orientation = 'gay';
>
> You've forgotten part of my premise (based on a real case I discussed on IRC)
> that there are EIGHTEEN criteria columns.

That is why I said maybe :-) Whether it helps depends on the number of
actually (often) used access patterns.

> That would require, by the method
> you have above, roughly 18(3rd factorial) indexes, times the number of values
> allowed by each column, which if it averaged, say 5 values, would be 24,480

Well, an index only needs to reduce the cost enough so that you can afford your
workload and have reasonable response times, so you might only need to create a
few of them.

I was actually only trying to help optimize this example without the "bitmap index"
feature, not trying to say that for this example "partial indexes" are better.
Especially since the first example, that mentioned partial indexes was not
"the way to do it" for a value that represents a large part of your table (here approx 50%).
(don't do: create index people_male on people (gender) where gender='male';)

Andreas

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Huxton 2004-10-14 08:15:31 Re: Networking feature for postgresql...
Previous Message gevik 2004-10-14 07:58:19 Embedded postgresql