Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
	by hub.org (8.9.3/8.9.3) with ESMTP id QAA57044
	for <pgsql-interfaces@postgreSQL.org>;
	Wed, 19 May 1999 16:30:46 -0400 (EDT)
	(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 QAA00956;
	Wed, 19 May 1999 16:29:04 -0400 (EDT)
To: eg@tzv.fal.de
cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] Postmaster getting veeeery big: SUBSTR bug 
In-reply-to: Your message of Wed, 19 May 1999 21:35:26 +0200
	<99051921401501.00833@salo.tzv.fal.de>
Date: Wed, 19 May 1999 16:29:04 -0400
Message-ID: <954.927145744@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Eildert Groeneveld <eg@tzv.fal.de> writes:
> Herouth was right in stating: "memory used for substr function" has to be
> the real cause of the problem because any substr select exhibits this
> behaviour:
> select substr(tets,1,2) from raw_field; 
> This one starts the postmaster at around 3MB and finishes at 40.
> Unfortunately, I have no idea about C, can someone identify the problem
> and come up with a patch?

The problem is well known and is on the TO-DO list: memory consumed
while evaluating expressions is not reclaimed until end of statement.
It's by no means specific to substr().

Unfortunately, fixing it is not a small amount of work (else it'd have
been done already).  I'm hoping to see it fixed in 6.6.

			regards, tom lane