Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION
От | Jeff Davis |
---|---|
Тема | Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION |
Дата | |
Msg-id | 1259138230.19289.253.camel@jdavis обсуждение исходный текст |
Ответ на | 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 Wed, 2009-11-25 at 09:23 +0100, Pavel Stehule wrote: > > If SRFs use a tuplestore in that situation, it sounds like that should > > be fixed. Why do we need to provide alternate syntax involving COPY? > > It isn't problem of SRF function design. It allow both mode - row and > tuplestor. select * from generate_series(1,1000000000) limit 1; That statement takes a long time, which indicates to me that it's materializing the result of the SRF. And there's no insert there. > This is problem of INSERT statement, resp. INSERT INTO > SELECT implementation. If "tmp" is a new table, and "zero" is a table with a million zeros in it, then: insert into tmp select 1/i from zero; fails instantly. That tells me that it's not materializing the result of the select; rather, it's feeding the rows in one at a time. Can show me in more detail what you mean? I'm having difficulty understanding your short replies. Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: