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

From Harald Fuchs
Subject Re: COPY Hacks (WAS: RE: Postgresql vs SQLserver for this application ?)
Date
Msg-id puwtreg4ke.fsf@srv.protecting.net
Whole thread Raw
In response to RE : RE: Postgresql vs SQLserver for this application ?  (bsimon@loxane.com)
List pgsql-performance
In article <1112813199.42542e8f17b4d@webmail.telus.net>,
Mischa <mischa.Sandberg@telus.net> writes:

> 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.

Using COPY from DBD::Pg _is_ documented - presumed you use DBD::Pg
version 1.41 released just today.

pgsql-performance by date:

Previous
From: "Douglas J. Trainor"
Date:
Subject: Re: How to improve db performance with $7K?
Next
From: Bruno Wolff III
Date:
Subject: Re: Recognizing range constraints (was Re: Plan for relatively simple query seems to be very inefficient)