Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > On Fri, Sep 02, 2005 at 04:02:08PM -0400, Tom Lane wrote:
> >> It has to be a *new* table, not an *empty* table. If it's already
> >> visible to other xacts then somebody else could insert into it in
> >> parallel with you, because COPY doesn't take an exclusive lock.
>
> > What about the indexes? Logging one of the inserters and not the other
> > is certain to corrupt the whole thing.
>
> Good point, but that fits in just fine with the restriction to
> just-created tables.
Seem the newly created table could have an index, but we would skip
logging on that too and create a zero-length file on crash restore.
> >> Contrariwise, it doesn't really matter (I think) if there are WAL-logged
> >> records already in the table and COPY is adding more that aren't logged.
>
> > Only if the page is locked in a fashion that the bulk loader can't
> > insert tuples into a page that the other transaction is using.
>
> What other transaction? The point I was making is that
> BEGIN;
> CREATE TABLE ...
> INSERT ...
> COPY ...
> is still optimizable. There isn't going to be anyone competing with
> the COPY while it runs.
Updated TODO:
o Allow COPY on a newly-created table to skip WAL logging
On crash recovery, the table involved in the COPY would
have its heap and index files truncated. One issue is
that no other backend should be able to add to the table
at the same time, which is something that is currently
allowed.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
