Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION
Date
Msg-id 1259355349.19289.536.camel@jdavis
Whole thread Raw
In response to Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Fri, 2009-11-27 at 13:39 +0000, Simon Riggs wrote:
> On Tue, 2009-11-24 at 22:13 -0800, Jeff Davis wrote:
> 
> > My disagreement with the row-by-row approach is more semantics than
> > performance. COPY translates records to bytes and vice-versa, and your
> > original patch maintains those semantics.
> 
> The bytes <-> records conversion is a costly one. Anything we can do to
> avoid that in either direction will be worth it. I would regard
> performance as being part/most of the reason to support this.
> 

Right. I was responding to an idea that copy support sending records
from a table to a function, or from a function to a table, which is
something that INSERT/SELECT can already do.

Our use case is a table to a remote table, so it would go something
like:1. COPY TO WITH BINARY on local node2. stream output bytes from #1 to remote node3. COPY FROM WITH BINARY on
remotenode
 

The only faster mechanism that I could imagine is sending the records
themselves, which would be machine-dependent.

Regards,Jeff Davis



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a
Next
From: Dave Cramer
Date:
Subject: OpenSSL key renegotiation with patched openssl