Re: COPY LOCK for WAL bypass

Поиск
Список
Период
Сортировка
Искать
От
Simon Riggs
Тема
Re: COPY LOCK for WAL bypass
Дата
Msg-id
1134978714.2964.232.camel@localhost.localdomain
Ответ на
Список
Дерево обсуждения
Re: COPY LOCK for WAL bypass Chris Browne <cbbrowne@acm.org>
Re: COPY LOCK for WAL bypass Simon Riggs <simon@2ndquadrant.com>
Re: COPY LOCK for WAL bypass "Jim C. Nasby" <jnasby@pervasive.com>
Re: COPY LOCK for WAL bypass Bruce Momjian <pgman@candle.pha.pa.us>
Re: COPY LOCK for WAL bypass Simon Riggs <simon@2ndquadrant.com>
Re: COPY LOCK for WAL bypass Simon Riggs <simon@2ndquadrant.com>
Re: COPY LOCK for WAL bypass Bruce Momjian <pgman@candle.pha.pa.us>
Re: COPY LOCK for WAL bypass Bruce Momjian <pgman@candle.pha.pa.us>
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.

I'll take the hint and write the docs then. :-)

Best Regards, Simon Riggs

В списке pgsql-patches по дате отправления
От: Chris Browne
Дата:
Сообщение: Re: COPY LOCK for WAL bypass
От: Pavel Stehule
Дата:
FAQ