Re: plans for bitmap indexes?

Tom,

> I've been taking "bitmap" to be a rather handwavy way of saying "a
> compact representation of sets of CTIDs that is readily amenable to
> being ANDed and ORed with other sets".

Well, actually I think we're talking about two different features:

1) a way to use more than one index per operation;
2) a more compact and thus faster index representation

The fact that Oracle solved both problems with the same code doesn't,
obviously mean that we have to. There's been a lot of discussion around
problem (2) on this thread, but I don't want to lose sight of problem
(1) .... especially since that's the problem faced by several active
community members right now.

You gave the impression that (1) could be implemented with regular BTree
indexes in an earlier e-mail. Would that be very hard to do?

> The whole thing starts to look like a self-adaptive
> interpolation between our present indexscan and seqscan techniques,
> which takes a lot of pressure off the planner to correctly guess the
> number of matching rows in advance.

This would be way cool.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco