<lnd@hnit.is> writes:
> A small comment on Oracle's implementation of persistent bitmap indexes:
>
> Oracle's bitmap index is concurently locked by DML, i.e. it suites for OLAP
> (basically read only data warehouses) but in no way for OLTP.
I knew this. I think they figured that was ok because bitmap indexes were
mainly intended to solve data warehouse problems anyways.
Thinking out loud here, I wonder whether this would be less of a problem for
postgres. Since tuples are never updated in place there would never be a need
to lock the entire bitmap until a transaction completes.
There would never be as much concurrency as btrees, assuming there was any
kind of compression on the bitmap, but I don't see any reason why a long-term
lock would have to be held for updates.
Even regular vacuum might not have to lock anything for long, just long enough
to clear the bits. and vacuum full/cluster already take table locks anyways.
I think the problem Oracle ran into was that storing rollback ids in the
bitmap is untenable. The whole point of persistent bitmap indexes is to store
a very dense representation that represents thousands of records per page.
Allocating space to store thousands of pending transaction ids and having
thousands of old versions of the page in the rollback segment would defeat the
purpose.
--
greg
