The attached patch adds an option to the COPY command to skip writing
WAL when the following conditions are all met:
1) The table is empty (zero size on disk)
2) The copy command can obtain an access exclusive lock on the table
with out blocking.
3) The WAL isn't needed for replication
COPY a FROM '/tmp/a.txt' (SKIP_WAL);
A non-default option to the copy command is required because the copy
will block out any concurrent access to the table which would be
undesirable in some cases and is different from the current behaviour.
This can safely be done because if the transaction does not commit the
empty version of the data files are still available. The COPY command
already skips WAL if the table was created in the current transaction.
There was a discussion on something similar before but I didn't see
any discussion of having it only obtain the lock if it can do so without
waiting (nor could I find in the archives what happened to that patch).
I'm not attached to the SKIP_WAL vs LOCK as the option
1- see http://archives.postgresql.org/pgsql-patches/2005-12/msg00206.php
pgsql-hackers by date
|Next:||From: Kevin Grittner||Date: 2011-08-23 18:07:33|
|Subject: Re: SSI 2PC coverage|
|Previous:||From: Jeff Davis||Date: 2011-08-23 17:23:28|
|Subject: Range Types|