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

Re: COPY LOCK for WAL bypass

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>,Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-patches(at)postgresql(dot)org
Subject: Re: COPY LOCK for WAL bypass
Date: 2005-12-21 16:23:52
Message-ID: 1135182232.2964.288.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-patches
On Wed, 2005-12-21 at 08:18 -0500, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > On Mon, Dec 19, 2005 at 07:51:54AM +0000, Simon Riggs wrote:
> > > On Sun, 2005-12-18 at 22:03 -0500, Chris Browne wrote:
> > > > simon(at)2ndquadrant(dot)com (Simon Riggs) writes:
> > > > > On Sat, 2005-12-10 at 12:07 +0000, Simon Riggs wrote:
> > > > >> Following patch implements COPY ... FROM ... LOCK
> > > > >
> > > > > Patch now updated so that it includes an additional optimization of
> > > > > COPY, so that WAL will not be written in the transaction that created
> > > > > the table.
> > > > >
> > > > > This now gives two fast paths for COPY:
> > > > > 1) COPY LOCK
> > > > > 2) COPY in same transaction (e.g. reloading a pg_dump)
> > > > 
> > > > I presume that if this doesn't go into WAL, that means that this kind
> > > > of update wouldn't play with PITR, right?
> > > 
> > > You're right.
> > > 
> > > PITR is designed for normal production use, rather than initial loading.
> > > It is also fairly common to turn PITR off permanently in larger data
> > > warehouses, which is also where these optimizations are aimed.
> > 
> > Hrm... I'd say we need an option to disable the fast-copy then, in case
> > you wanted the copy to make it into PITR. Or perhaps we just disallow
> > the fast-copy when PITR is in use. I believe that's what other databases
> > do...
> 
> Right, just disable with a clear error message.
> 

Forgive me if my earlier reply was not clear: This patch works just the
same way CREATE INDEX and CREATE TABLE AS SELECT already works:
- if the server has archive_command set, WAL is written
- if archive_command is not set then (assuming other conditions apply)
the writing WAL will be bypassed for performance.
There is no error-message generated, by COPY LOCK nor the other two
previously mentioned commands.

Writing docs now.

Best Regards, Simon Riggs


In response to

Responses

pgsql-patches by date

Next:From: Simon RiggsDate: 2005-12-21 17:15:19
Subject: Re: COPY LOCK for WAL bypass
Previous:From: Bruce MomjianDate: 2005-12-21 16:04:34
Subject: Re: [GENERAL] Converting seconds past midnight to a time

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