Re: On-disk bitmap index implementation

Heikki Linnakangas wrote:
> We need to give the indexam API some further thought. As you know, I've
> been working on the Grouped Index Tuples stuff, which also requires
> changes to the API to get full benefit. There's a bunch of functionality
> I'd like to see:
>
> * Support for streamed bitmaps, like you have implemented.
>
> * Support for candidate matches. This is needed for GIT, as well as
> range-encoded bitmap indexes if/when we add them.
>
> * Support for returning tuples in partial order. This is again needed
> for GIT, because grouped tuples don't keep track of the ordering within
> the group, so they need to be sorted if ordering necessary. And again
> it's also useful to return tuples in order from range-encoded bitmaps.
>
> * Support for kill_prior_tuple on bitmap scans.
>
> * A bulk insert API. When inserting a lot of tuples with similar keys,
> we could a considerable amount of CPU with a bulk insert API. A bulk
> insert to a B-tree for example would only need to descend the tree once,
> find the insert location, lock the target page just once and insert all
> the tuples that belong to that page. That would potentially also reduce
> WAL traffic.

Forgot one:

* Ability return index tuple contents, not just pointers to heap, to
allow the executor to use the values stored in the index, see
http://archives.postgresql.org/pgsql-performance/2006-09/msg00080.php

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com