On Wed, 2005-06-01 at 14:14 -0400, Tom Lane wrote: > So what I'm thinking is we need no special WAL entries for this. What > we need is just an operating mode of COPY in which it doesn't WAL-log > its inserts, but instead fsyncs before completion, much like index build > does. For safety it must do all its inserts into freshly-added pages; > this is not to ensure truncatability, because we aren't going to do that > anyway, but to ensure that we don't have unlogged operations changing > pages that might contain committed tuples. (That would pose a risk of > losing committed data to incomplete writes in case of system crash > partway through. The same reason is why we need exclusive lock: else > we might end up with pages containing a mix of logged and unlogged > tuples.) Also there can be no indexes, since we don't want index > entries pointing to unlogged tuples. And PITR can't be enabled. > Otherwise no problem.
What you describe above is a coherent set of features that provide most of the benefits I sought, plus some others. We also don't mess with WAL, which is grand thing. We gain the ability to load into tables with rows already in them. I don't agree with all of your other points, but given time schedules, I think that we win with the above, so forget the rest. The main COPY/LOAD DATA discussion is on another thread of this from Alon, who has some interesting ideas and some really cool performance results to share. Best Regards, Simon Riggs ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]