| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Protecting against unexpected zero-pages: proposal |
| Date: | 2010-11-09 19:37:05 |
| Message-ID: | 4CD9A2E1.8090708@agliodbs.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2010-11-09 19:41:32 | Re: proposal: plpgsql - iteration over fields of rec or row variable |
| Previous Message | Robert Haas | 2010-11-09 19:23:57 | Re: TODO Alter Table Rename Constraint |