On Tue, Nov 9, 2010 at 7:37 PM, Josh Berkus <j...@agliodbs.com> wrote: > Well, most of the other MVCC-in-table DBMSes simply don't deal with > large, on-disk databases. In fact, I can't think of one which does, > currently; while MVCC has been popular for the New Databases, they're > all focused on "in-memory" databases. Oracle and InnoDB use rollback > segments.
Well rollback segments are still MVCC. However Oracle's MVCC is block-based. So they only have to do the visibility check once per block, not once per row. Once they find the right block version they can process all the rows on it. Also Oracle's snapshots are just the log position. Instead of having to check whether every transaction committed or not, they just find the block version which was last modified before the log position for when their transaction started. > Might be worth asking the BDB folks. > > Personally, I think we're headed inevitably towards having a set of > metadata bitmaps for each table, like we do currently for the FSM. Well we already have a metadata bitmap for transaction visibility. It's called the clog. There's no point in having one structured differently around the table. The whole point of the hint bits is that it's in the same place as the data. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
