Re: Protecting against unexpected zero-pages: proposal
От | Josh Berkus |
---|---|
Тема | Re: Protecting against unexpected zero-pages: proposal |
Дата | |
Msg-id | 4CD9A2E1.8090708@agliodbs.com обсуждение исходный текст |
Ответ на | Re: Protecting against unexpected zero-pages: proposal (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Protecting against unexpected zero-pages: proposal
|
Список | pgsql-hackers |
> PostgreSQL > isn't the only database product that uses MVCC - not by a long shot - > and the problem of detecting whether an XID is visible to the current > snapshot can't be ours alone. So what do other people do about this? > They either don't cache the information about whether the XID is > committed in-page (in which case, are they just slower or do they have > some other means of avoiding the performance hit?) or they cache it in > the page (in which case, they either WAL log it or they don't checksum > it). 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. 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. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com
В списке pgsql-hackers по дате отправления: