Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION
Date
Msg-id 1259138230.19289.253.camel@jdavis
Whole thread Raw
In response to Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses 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
List 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 by date:

Previous
From: Itagaki Takahiro
Date:
Subject: Re: SE-PgSQL patch review
Next
From: KaiGai Kohei
Date:
Subject: Re: SE-PgSQL patch review