Re: COPY LOCK for WAL bypass
От | Jim C. Nasby |
---|---|
Тема | Re: COPY LOCK for WAL bypass |
Дата | |
Msg-id | 20051220184727.GA28771@pervasive.com обсуждение исходный текст |
Ответ на | Re: COPY LOCK for WAL bypass (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: COPY LOCK for WAL bypass
|
Список | 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@2ndquadrant.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@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
В списке pgsql-patches по дате отправления: