Re: plans for bitmap indexes? - Mailing list pgsql-hackers

From Zeugswetter Andreas DAZ SD
Subject Re: plans for bitmap indexes?
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA40184D1E3@m0114.s-mxs.net
Whole thread Raw
In response to plans for bitmap indexes?  (Yann Michel <yann-postgresql@spline.de>)
List 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


pgsql-hackers by date:

Previous
From: gevik@xs4all.nl
Date:
Subject: Embedded postgresql
Next
From: Richard Huxton
Date:
Subject: Re: [GENERAL] Networking feature for postgresql...