Re: plans for bitmap indexes?

Hannu Krosing <hannu(at)tm(dot)ee> writes:

> so if I change foo=1 to foo=2 on a tuple that has bar=2 and baz=3 then
> the updated tuple will go to a page for which foo=2, bar=2 and baz=3.
>
> if no such page has enough free space left (found by anding bitmaps for
> foo=2, bar=2 and baz=3 and FSM) then a new page is inserted and the
> three corresponding indexes are updated to include that page.

This is all thinking in terms of a single index though. What do you do if I
have a dozen bitmap indexes? Each could have a 10 distinct values. You would
need 100,000 pages, each of which might only have a few tuples in them.

In any case the user may prefer to have the data clustered around a btree
index using the existing CLUSTER command.

There's a logical separation between the idea of index methods and table
storage mechanisms. Trying to implement something like this that breaks that
abstraction will only make things far more confusing.

I think what you're trying to accomplish is better accomplished through
partitioned tables. Then the user can decide which keys to use to partition
the data and the optimizer can use the data to completely exclude some
partitions from consideration. And it wouldn't interfere with indexes to
access the data within a partition.

--
greg