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

Re: NOLOGGING option, or ?

From: Alvaro Herrera <alvherre(at)surnet(dot)cl>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hannu Krosing <hannu(at)skype(dot)net>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: NOLOGGING option, or ?
Date: 2005-06-01 17:18:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Jun 01, 2005 at 06:00:28PM +0100, Simon Riggs wrote:
> On Wed, 2005-06-01 at 11:31 -0400, Tom Lane wrote:

> > Perhaps it could work to use an ALTER TABLE command to flip the state.
> > But I'm not really seeing the point compared to treating it as a COPY
> > option.  I do not believe that anyone needs this to work on individual
> > INSERT commands --- if you are after max speed, why aren't you using
> > COPY?  And treating it as an ALTER property opens the possibility of
> > forgetting to ALTER the table back to normal behavior, which would be
> > a foot-gun of large caliber indeed :-(
> Oh no, not the foot gun again. I surrender.

Sorry, what are you surrendering from/for/of/to?  I think the proposal
is doing a reasonable headways.  So far we have

- it is an option to COPY and CREATE TABLE AS, not GUC, not ALTER TABLE
- it'd only work on empty tables
- it'd only work it PITR is off
- it needs to follow MVCC semantics, i.e. the tuples need to be written
  with the correct Xids
- after the command is done, an fsync is applied to the table file(s)

Another point that needs thought is what to do if the table has any
indexes.  Are operations on said indexes logged or not?  Maybe we should
just say that indexes are verbotten and the user needs to create them

Alvaro Herrera (<alvherre[a]>)
"Las cosas son buenas o malas segun las hace nuestra opinión" (Lisias)

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2005-06-01 17:35:25
Subject: Re: NOLOGGING option, or ?
Previous:From: Simon RiggsDate: 2005-06-01 17:00:28
Subject: Re: NOLOGGING option, or ?

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