Neil Conway <[EMAIL PROTECTED]> writes: > Jon Jensen wrote: >> How would you do a rollback if an error occurred mid-query? How would you >> keep your table from being a big pile of junk if a power failure happened >> during the query?
> As most non-MVCC database do: by writing WAL records. > In theory, it seems to me that we could implement an overwriting > storage manager for PostgreSQL (i.e. we'd have both MVCC and non-MVCC, > and allow users to choose at runtime). It would require a *lot* of > work, but I can't see any fundamental reason why it wouldn't be possible. It would be possible, but what's the point? There's no evidence that this approach is superior to what we do, and a fair number of reasons to think it's inferior. In particular, with this approach you have to maintain the entire history of a transaction in WAL, so that you have the info available to roll back if it aborts. So the OP's concern about needing 2X the disk space to update his table still applies, it's just in a different place. It's true that it's easier to get the space back when no longer needed --- VACUUM FULL is expensive if it's moving lots of records. But in general I think our VACUUM-based approach is superior to the Oracle-style UNDO approach, because it pushes the maintenance overhead out of foreground transaction processing and into a schedulable background process. Certainly any Oracle DBA will tell you that huge transactions are a headache to handle in Oracle. I think what the OP actually wanted us to offer was non-transaction-safe overwrite-in-place updating. That might be technically feasible (not sure how we'd deal with changes in indexed columns though). But it's so contrary to the basic design goals of the project that I don't think anyone will take the suggestion seriously. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]