Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
	by hub.org (8.9.3/8.9.3) with ESMTP id TAA47981
	for <pgsql-interfaces@postgreSQL.org>;
	Thu, 2 Dec 1999 19:42:36 -0500 (EST)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id TAA29677;
	Thu, 2 Dec 1999 19:41:29 -0500 (EST)
To: dougt@mugc.cc.monash.edu.au
cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] Back end memory consumption (was Front end memory
	consumption in SELECT)
In-reply-to: Your message of Fri, 3 Dec 1999 10:30:10 +1100 (EST)
	<199912022330.KAA03178@mugca.cc.monash.edu.au>
Date: Thu, 02 Dec 1999 19:41:29 -0500
Message-ID: <29675.944181689@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Douglas Thomson <dougt@mugc.cc.monash.edu.au> writes:
> I have just noticed that the back end process swells to
> the total size of all the tables involved in my query for the
> duration of the SELECT (or is it the duration of the declared cursor
> now?).

The life of the cursor, probably, but I'm a little surprised by this.

> To summarise the situation:
>     - I am attempting a join on 9 tables, using a cursor to fetch the
>       selected data
>     - the back end process grows to over 20M while processing my query

What query plan does EXPLAIN show for your SELECT?

			regards, tom lane