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

Re: NOLOGGING option, or ?

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Greg Stark <gsstark(at)MIT(dot)EDU>
Cc: Neil Conway <neilc(at)samurai(dot)com>,Alvaro Herrera <alvherre(at)surnet(dot)cl>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: NOLOGGING option, or ?
Date: 2005-06-01 08:44:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Greg Stark <gsstark(at)MIT(dot)EDU> writes:

> For CREATE TABLE AS in the non-PITR case you don't really need to WAL log the
> records at all. If it fails in the middle you just drop the table. When it
> completes you do a checkpoint before acknowledging the COMMIT.
> I think this is already done for CREATE INDEX/REINDEX, also only in the
> non-PITR case.

Sorry to followup to my own message, but it occurs to me that COPY could be
made to automatically do this for the case of an empty destination table too.

I'm not sure if it should automatically check for an empty table or if there
should be an option for the user to indicate he wants COPY to replace the
current contents entirely. The latter might actually be more useful. .

But either way, you just WAL log a record indicating that the table should be
entirely empty. Then you fill it up without logging anything. Do a checkpoint
and then WAL log that the COPY is finished. If any failure occurs replay
leaves it empty.

Again this sadly only works in the non-PITR case.


In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2005-06-01 08:50:09
Subject: Re: Cost of XLogInsert CRC calculations
Previous:From: Hans-Jürgen SchönigDate: 2005-06-01 08:35:06
Subject: Re: regarding storage in postgres

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