Skip site navigation (1) Skip section navigation (2)

Re: NOLOGGING option, or ?

From: Alvaro Herrera <alvherre(at)surnet(dot)cl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: NOLOGGING option, or ?
Date: 2005-06-01 04:40:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, May 31, 2005 at 10:47:30PM -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)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]>) interfaz de línea de comando para la web.

In response to


pgsql-hackers by date

Next:From: Michael GlaesemannDate: 2005-06-01 04:42:53
Subject: Re: Interval->day proposal
Previous:From: Michael GlaesemannDate: 2005-06-01 04:20:25
Subject: Re: Interval->day proposal

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group