Horton

Re: NOLOGGING option, or ?

Hannu Krosing <hannu@skype.net>

View thread
From: Hannu Krosing <hannu@skype.net>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Hans-Jürgen Schönig <postgres@cybertec.at>, Neil Conway <neilc@samurai.com>, Alvaro Herrera <alvherre@surnet.cl>, Alon Goldshuv <agoldshuv@greenplum.com>, pgsql-hackers@postgresql.org
Date: 2005-06-01T09:54:58Z
Lists: pgsql-hackers 
On K, 2005-06-01 at 09:16 +0100, Simon Riggs wrote:
> On Tue, 2005-05-31 at 22:47 -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.
> > 
> > How much of that is left after we fix the 64-bit-CRC issue?
> 
> Well, I don't know. The I/O is the main thing I'm trying to avoid.

While avoiding IO is a good thing in general, WAL IO traffic can at
least easily made parallel to other IO by allocating own disk for WAL.

> > > Now, I would like to discuss adding an enable_logging USERSET GUC,
> > 
> > [ fear and loathing ... ]
> 
> OK. I needed to say the idea, to make sure we had considered it. I now
> pronounce it dead and buried.
> 
> > BTW, I'm sure you are the last one who needs to be reminded that
> > any such thing breaks PITR completely.  

I don't think we do any WAlling of TEMP tables, so it may be easy to
extend this to any table with 'NO_WAL' bit set.

That would create kind of 'extended temp table' - unsafe but fast ;)

-- 
Hannu Krosing <hannu@skype.net>