On Wed, Jun 01, 2005 at 06:55:46PM +0100, Simon Riggs wrote: > On Wed, 2005-06-01 at 11:55 -0400, Tom Lane wrote: > > Simon Riggs <[EMAIL PROTECTED]> writes: > > > 4. Optionally, we set a flag on the table showing the whole table is > > > frozen. Anybody writing to this table subsequently will spoil this flag. > > > If the flag is set, all forms of VACUUM will return success immediately > > > without performing a scan (since it is already in a perfect VACUUM FULL > > > and VACUUM FREEZE state). > > > > This bit strikes me as dangerous and not related to the original > > proposal. I don't care for the load-already-frozen-data part at all, > > either. That's not just giving up WAL protection, that's an outright > > MVCC semantics violation, in return for which we get ... not much. > > Certainly not any speedup in the LOAD itself. > > I agree it *sounds* dangerous, but is it? If so, how? I will immediately > withdraw any idea that proves dangerous. > > We're holding the table lock and will continue to do so until end of > transaction. No transaction with an earlier id will ever see the data we > load because of the lock.
Suppose you load half the tuples and the plug is pulled. After recovery, you have half-load of tuples that are visible to everyone. This is a no-no. Plus, what is the benefit of having the tuples in frozen state to start with? If this is a data warehouse application, I'd expect the table to be dropped or truncated rather before the billion-transactions barrier comes to pass. -- Alvaro Herrera (<alvherre[a]surnet.cl>) "I dream about dreams about dreams", sang the nightingale under the pale moon (Sandman) ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org