<[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings