Re: Protecting against unexpected zero-pages: proposal - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Protecting against unexpected zero-pages: proposal
Date
Msg-id AANLkTikDz-kheq4e3WcfPcyLwrmJ0iCJwHh2ZKznSonK@mail.gmail.com
Whole thread Raw
In response to Re: Protecting against unexpected zero-pages: proposal  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Protecting against unexpected zero-pages: proposal
Re: Protecting against unexpected zero-pages: proposal
List pgsql-hackers
On Tue, Nov 9, 2010 at 7:37 PM, Josh Berkus <josh@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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: proposal: plpgsql - iteration over fields of rec or row variable
Next
From: Josh Berkus
Date:
Subject: Re: Protecting against unexpected zero-pages: proposal