From: | Daniel Farina <dfarina(at)truviso(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION |
Date: | 2009-11-24 00:03:38 |
Message-ID: | 429f3b220911231603pe3c3635v18f729bca5122792@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 23, 2009 at 3:46 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> I recently found myself trying to push data through dblink() and ended up
> writing code to make a call to the target to call a function which called
> back to the source to select the data and insert it. The speedup was
> massive, so I'll be interested to dig into the details here.
The way the indirection is accomplished here should be very cheap.
Overhead should be comparable to the fwrite() call that is used for
copying to a file...this is why I mentioned that it would be
interesting to make this good enough to be the underlying mechanism of
TO STDOUT/TO 'file' to reduce the overall number of mechanisms used to
perform COPY TO.
> I'm also interested in COPY returning rows as text[], which was discussed
> recently. Does this help move us towards that?
Yes. Take a look at the tests introduced to core PostgeSQL (see patch
2), where instead of returning a text[] I return just a single text of
the verbatim output of the copy. You could imagine making that an SRF
instead. It would have to understand COPY row delimiters in whatever
mode you were operating in, though.
fdr
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Farina | 2009-11-24 00:06:34 | Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION |
Previous Message | Andrew Dunstan | 2009-11-23 23:46:07 | Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION |