From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: COPY LOCK for WAL bypass |
Date: | 2005-12-20 18:47:27 |
Message-ID: | 20051220184727.GA28771@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
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...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2005-12-20 21:37:26 | Re: PLpgSQL: list of scalars as row for assign stmt, fore and fors stm |
Previous Message | Jim C. Nasby | 2005-12-20 18:42:17 | Re: [BUGS] Solaris cc compiler on amd: PostgreSQL does not |