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: 1117619698.4772.14.camel@fuji.krosing.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

Browse pgsql-hackers by date

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