Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION

2009/11/25 Jeff Davis <pgsql(at)j-davis(dot)com>:
> On Wed, 2009-11-25 at 06:35 +0100, Pavel Stehule wrote:
>> I believe so using an "internal" minimalize necessary changes in COPY
>> implementation. Using a funcapi needs more work inside COPY -  you
>> have to take some functionality from COPY to stream functions.
>> Probably the most slow operations is parsing - calling a input
>> functions. This is called once every where. Second slow operation is
>> reading from network - it is same. So I don't see too much reasons,
>> why non internal implementation have to be significant slower than
>> your actual implementation. I am sure, so it needs more work.
>
> I apologize, but I don't understand what you're saying. Can you please
> restate with some examples?
>
> It seems like you're advocating that we move records from a table into a
> function using COPY. But that's not what COPY normally does: COPY
> normally translates records to bytes or bytes to records.
>
> Moving records from a table to a function can be done with:
>  SELECT myfunc(mytable) FROM mytable;
> already. The only problem is if you want initialization/destruction. But
> I'm not convinced that COPY is the best tool to provide that.
>
> Moving records from a function to a table can be done with:
>  INSERT INTO mytable SELECT * FROM myfunc();
> And that already works fine.

It works, but COPY FROM myfunc() should be significantly faster. You
can skip tuple store.

Pavel

>
> So what use case are you concerned about?
>
> Regards,
>        Jeff Davis
>
>