Received: from jupiter.tzv.fal.de (jupiter.tzv.fal.de [192.108.34.1])
	by hub.org (8.9.3/8.9.3) with ESMTP id NAA38181
	for <pgsql-interfaces@postgresql.org>;
	Wed, 19 May 1999 13:57:42 -0400 (EDT)
	(envelope-from eg@salo.tzv.fal.de)
Received: from salo.tzv.fal.de (eg@salo [192.108.34.39]) by jupiter.tzv.fal.de
	(8.8.5/8.7.3) with ESMTP id TAA19238 for
	<pgsql-interfaces@postgresql.org>;
	Wed, 19 May 1999 19:57:02 +0200 (MET DST)
Received: from [[UNIX: localhost]] ([[UNIX: localhost]])
	by salo.tzv.fal.de (8.8.7/8.8.7) id VAA00836
	for pgsql-interfaces@postgresql.org; Wed, 19 May 1999 21:40:15 +0200
From: Eildert Groeneveld <eg@tzv.fal.de>
Reply-To: eg@tzv.fal.de
Organization: FAL
To: pgsql-interfaces@postgresql.org
Subject: Postmaster getting veeeery big: SUBSTR bug
Date: Wed, 19 May 1999 21:35:26 +0200
X-Mailer: KMail [version 1.0.21]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99051921401501.00833@salo.tzv.fal.de>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id NAA38182

Never mind my initial query, it was just used for demonstration purposes.
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?

greetings

Eildert Groeneveld
=========================================
Institute for
Animal Science and Animal Behaviour
Mariensee 31535 Neustadt Germany
Tel   : (49)(0)5034 871155
Fax   : (49)(0)5034 92579
www   : http://www.tzv.fal.de/~eg/ 
e-mail: eg@tzv.fal.de
=========================================