COPY Hacks (WAS: RE: Postgresql vs SQLserver for this application ?) - Mailing list pgsql-performance

From Mischa
Subject COPY Hacks (WAS: RE: Postgresql vs SQLserver for this application ?)
Date
Msg-id 1112813199.42542e8f17b4d@webmail.telus.net
Whole thread Raw
In response to Re: RE : RE: Postgresql vs SQLserver for this application ?  (Alex Turner <armtuk@gmail.com>)
Responses Re: COPY Hacks (WAS: RE: Postgresql vs SQLserver for this application ?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: COPY Hacks (WAS: RE: Postgresql vs SQLserver for this  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Re: COPY Hacks (WAS: RE: Postgresql vs SQLserver for this application ?)  ("Greg Sabino Mullane" <greg@turnstep.com>)
List pgsql-performance
This thread seems to be focusing in on COPY efficiency,
I'd like to ask something I got no answer to, a few months ago.

Using COPY ... FROM STDIN via the Perl DBI (DBD::Pg) interface,
I accidentally strung together several \n-terminated input lines,
and sent them to the server with a single "putline".

To my (happy) surprise, I ended up with exactly that number of rows
in the target table.

Is this a bug? Is this fundamental to the protocol?

Since it hasn't been documented (but then, "endcopy" isn't documented),
I've been shy of investing in perf testing such mass copy calls.
But, if it DOES work, it should be reducing the number of network
roundtrips.

So. Is it a feechur? Worth stress-testing? Could be VERY cool.

--
"Dreams come true, not free."


pgsql-performance by date:

Previous
From: Alex Turner
Date:
Subject: Re: Réf
Next
From: Rod Taylor
Date:
Subject: Re: Réf