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

Re: NOLOGGING option, or ?

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>,Neil Conway <neilc(at)samurai(dot)com>, Alvaro Herrera <alvherre(at)surnet(dot)cl>,Alon Goldshuv <agoldshuv(at)greenplum(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: NOLOGGING option, or ?
Date: 2005-06-01 09:54:58
Message-ID: (view raw, whole thread or download thread mbox)
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(at)2ndquadrant(dot)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(at)skype(dot)net>

In response to

pgsql-hackers by date

Next:From: Zeugswetter Andreas DAZ SDDate: 2005-06-01 11:07:57
Subject: Re: Tablespace-level Block Size Definitions
Previous:From: Mark Cave-AylandDate: 2005-06-01 09:27:41
Subject: Re: Cost of XLogInsert CRC calculations

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