Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION
От | Daniel Farina |
---|---|
Тема | Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION |
Дата | |
Msg-id | 7b97c5a40911240237m6e23fb4fh977ab1e4196da776@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: [PATCH 4/4] Add tests to dblink covering use of COPY
TO FUNCTION
Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION |
Список | pgsql-hackers |
On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > Hello > > I thing, so this patch is maybe good idea. I am missing better > function specification. Specification by name isn't enough - we can > have a overloaded functions. This syntax doesn't allow to use explicit > cast - from my personal view, the syntax is ugly - with type > specification we don't need to keyword FUNCTION As long as things continue to support the INTERNAL-type behavior for extremely low overhead bulk transfers I am open to suggestions about how to enrich things...but how would I do so under this proposal? I am especially fishing for suggestions in the direction of managing state for the function between rows though...I don't like how the current design seems to scream "use a global variable." > We have a fast copy statement - ok., we have a fast function ok, but > inside a function we have to call "slow" sql query. Personally What is > advantage? The implementation here uses a type 'internal' for performance. It doesn't even recompute the fcinfo because of the very particular circumstances of how the function is called. It doesn't do a memory copy of the argument buffer either, to the best of my knowledge. In the dblink patches you basically stream directly from the disk, format the COPY bytes, and shove it into a waiting COPY on another postgres node...there's almost no additional work in-between. All utilized time would be some combination of the normal COPY byte stream generation and libpq. This, of course, presumes that everyone who is interested in building on this is going to use some UDFs written in C... > > We need pipes like > > like COPY table TO foo(..) TO table > > foo() should be a transformation function, or real pipe function I've actually considered this pipe thing with a colleague while driving home from work...it occurred to us that it would be nice to have both pipes and tees (basically composition vs. mapping application of functions over the input) in some form. Not sure what an elegant way to express that is or how to control it. Since you can work around this by composing or applying functions on your own in another function, I'm not sure if that's as high priority for me personally. fdr
В списке pgsql-hackers по дате отправления: