Re: NOLOGGING option, or ? - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: NOLOGGING option, or ?
Date
Msg-id 20050601044007.GD19034@surnet.cl
Whole thread Raw
In response to Re: NOLOGGING option, or ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: NOLOGGING option, or ?
List pgsql-hackers
On Tue, May 31, 2005 at 10:47:30PM -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > Recent test results have shown a substantial performance improvement
> > (+25%) if WAL logging is disabled for large COPY statements.

> BTW, I'm sure you are the last one who needs to be reminded that
> any such thing breaks PITR completely.  Which is surely sufficient
> reason not to let it be USERSET.

This doesn't work for COPY, but maybe for CREATE TABLE AS we could log
the fact that the command was executed, so the replayer could execute
the same command again.

Of course, this handwaving doesn't explain how the system in recovery
mode would be able to execute a full query to reconstruct the table, and
also it doesn't say a lot about the extra complexity at the source level
to implement this option.

For people loading big files into the database, maybe we could think
about a command to let a file be loaded directly as initial table
content.  So all that we'd need is a program to write the file, which
could be done externally (The filewriter would have to have access to
the catalog and input functions for the involved types, though I think
for simple types it would be straighforward ... we could write frozen
tuples to avoid TransactionId problems.)

-- 
Alvaro Herrera (<alvherre[a]surnet.cl>)
www.google.com: interfaz de línea de comando para la web.


pgsql-hackers by date:

Previous
From: Michael Glaesemann
Date:
Subject: Re: Interval->day proposal
Next
From: Michael Glaesemann
Date:
Subject: Re: Interval->day proposal