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

In response to

• Re: NOLOGGING option, or ? at 2005-06-01 18:14:27 from Tom Lane

pgsql-hackers by date

Next:	From: Meredith L. Patterson	Date: 2005-06-01 20:50:33
	Subject: Re: Google's Summer of Code ...
Previous:	From: Oleg Bartunov	Date: 2005-06-01 20:29:57
	Subject: Re: Google's Summer of Code ...