On Tue, Nov 24, 2009 at 9:35 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > 2009/11/25 Daniel Farina <drfar...@gmail.com>: >> On Tue, Nov 24, 2009 at 8:45 PM, Pavel Stehule <pavel.steh...@gmail.com> >> wrote: >>> It depends on design. I don't thing so internal is necessary. It is >>> just wrong design. >> >> Depends on how lean you want to be when doing large COPY...right now >> the cost is restricted to having to call a function pointer and a few >> branches. If you want to take SQL values, then the semantics of >> function calling over a large number of rows is probably notably more >> expensive, although I make no argument against the fact that the >> non-INTERNAL version would give a lot more people more utility. > > 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.
You are probably right. We could try coercing to bytea and back out to bytes, although it seems like a superfluous cost to force *everyone* to pay just to get the same bytes to a network buffer. fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers