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: | 874qciv53r.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2005-06-01 08:50:09 | Re: Cost of XLogInsert CRC calculations |
Previous Message | Hans-Jürgen Schönig | 2005-06-01 08:35:06 | Re: regarding storage in postgres |