I tried to prepare a patch for these TODO items:
- Have COPY return the number of rows loaded/unloaded?
- Update [pg_dump and] psql to use the new COPY libpq API.
Added an uint64 processed to struct CopyStateData. It's
incremented each time on a tuple send/receive made by
CopyTo/CopyFrom.
On Sat, 2005-12-17 at 20:03 +0100, Peter Eisentraut wrote:
Simon Riggs wrote:
Changes as discussed. singletransaction.patch attached.
I meant to ask, why is this not the default or only behavior?
Historically, it didn't work that way, so I hadn't thought to change
that behaviour. We could
Tom Lane wrote:
I believe Peter's question was rhetorical: what he meant to point out
is that the documentation needs to explain what is the reason for
having this switch, ie, in what cases would you use it or not use it?
Just saying what it does isn't really adequate docs.
I once considered
On Sun, 2005-12-18 at 14:04 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Sat, 2005-12-17 at 20:03 +0100, Peter Eisentraut wrote:
I meant to ask, why is this not the default or only behavior?
Historically, it didn't work that way, so I hadn't thought to change
that
On Sat, 2005-12-10 at 12:07 +, 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)
On Sun, 2005-12-18 at 21:51 +0100, Peter Eisentraut wrote:
Tom Lane wrote:
I believe Peter's question was rhetorical: what he meant to point out
is that the documentation needs to explain what is the reason for
having this switch, ie, in what cases would you use it or not use it?
Just
Test.
--
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
Peter Eisentraut [EMAIL PROTECTED] writes:
I once considered implementing this myself but found it infeasible for
some reason I don't remember. Nevertheless I always thought that
having an atomic restore ought to be a non-optional feature. Are there
situations where one would not want to
[EMAIL PROTECTED] (Simon Riggs) writes:
On Sat, 2005-12-10 at 12:07 +, 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.
