Re: Protecting against unexpected zero-pages: proposal

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Protecting against unexpected zero-pages: proposal
Дата
Msg-id AANLkTikDz-kheq4e3WcfPcyLwrmJ0iCJwHh2ZKznSonK@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Protecting against unexpected zero-pages: proposal  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Protecting against unexpected zero-pages: proposal  (Josh Berkus <josh@agliodbs.com>)
Re: Protecting against unexpected zero-pages: proposal  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: proposal: plpgsql - iteration over fields of rec or row variable
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Protecting against unexpected zero-pages: proposal