X-Original-To: pgsql-docs-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id D4C2D52B3E;
	Sat, 30 Jul 2005 10:48:04 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 54028-05; Sat, 30 Jul 2005 13:48:01 +0000 (GMT)
Received: from trolak.mydnsbox2.com (ns1.mydnsbox2.com [207.44.142.118])
	by svr1.postgresql.org (Postfix) with ESMTP id A5B4652B34;
	Sat, 30 Jul 2005 10:47:59 -0300 (ADT)
Received: from [192.168.1.103] (cpe-024-211-165-134.nc.res.rr.com
	[24.211.165.134]) (authenticated (0 bits))
	by trolak.mydnsbox2.com (8.11.6/8.11.6) with ESMTP id j6UD2eZ08220;
	Sat, 30 Jul 2005 08:02:41 -0500
Message-ID: <42EB850E.9080205@dunslane.net>
Date: Sat, 30 Jul 2005 09:47:58 -0400
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Fetter <david@fetter.org>
Cc: PostgreSQL Patches <pgsql-patches@postgresql.org>,
	PostgreSQL Docs <pgsql-docs@postgresql.org>,
	Bruce Momjian <pgman@candle.pha.pa.us>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Michael Fuhr <mike@fuhr.org>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] PL/Perl list value return causes segfault
References: <42D44731.90306@dunslane.net>
	<200507300324.j6U3Ob713189@candle.pha.pa.us>
	<20050730054354.GL27147@fetter.org>
In-Reply-To: <20050730054354.GL27147@fetter.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.051 tagged_above=0 required=5 tests=AWL
X-Spam-Level: 
X-Archive-Number: 200508/5
X-Sequence-Number: 3167



David Fetter wrote:

>*** 716,724 ****
>  
>      <listitem>
>       <para>
>!       In the current implementation, if you are fetching or returning
>!       very large data sets, you should be aware that these will all go
>!       into memory.
>       </para>
>      </listitem>
>     </itemizedlist>
>--- 766,776 ----
>  
>      <listitem>
>       <para>
>!       If you are fetching or returning very large data sets using
>!       <literal>spi_exec_query</literal>, you should be aware that
>!       these will all go into memory.  You can avoid this by using
>!       <literal>spi_query</literal>/<literal>spi_fetchrow</literal> as
>!       illustrated earlier.
>       </para>
>      </listitem>
>     </itemizedlist>
>  
>
>  
>

You have rolled 2 problems into one - spi_query+spi_fetchrow does not 
address the issue of returning large data sets.

Suggest instead:

<para>

       If you are fetching very large data sets using
       <literal>spi_exec_query</literal>, you should be aware that
       these will all go into memory.  You can avoid this by using
       <literal>spi_query</literal> and <literal>spi_fetchrow</literal> 
	as illustrated earlier.
</para>
<para>
	A similar problem occurs if a set-returning function passes 
	a large set of rows back to postgres via 
	<literal>return</literal>. You can avoid this 
	problem too by instead using <literal>return_next</literal> for 
	each row returned, as shown previously.
</para>




cheers

andrew