Message-ID: <44845F99.7050306@dunaweb.hu>
Date: Mon, 05 Jun 2006 18:45:13 +0200
From: Zoltan Boszormenyi <zboszor@dunaweb.hu>
User-Agent: Thunderbird 1.5.0.2 (X11/20060501)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Jim C. Nasby" <jnasby@pervasive.com>,
	pgsql-hackers@postgresql.org
Subject: Re: [PERFORM] psql -A (unaligned format) eats too much
References: <44835834.2020309@dunaweb.hu> <44835F86.5040008@dunaweb.hu>
	<20060605152258.GT53487@pervasive.com>
	<20512.1149521250@sss.pgh.pa.us>
In-Reply-To: <20512.1149521250@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 8bit

Hi!

Tom Lane írta:
> "Jim C. Nasby" <jnasby@pervasive.com> writes:
>   
>> I've been able to verify this on 8.1.4; psql -A -t -c 'SELECT * FROM
>> largetable' > /dev/null results in psql consuming vast quantities of
>> memory. Why is this?
>>     
>
> Is it different without the -A?
>
> I'm reading this as just another uninformed complaint about libpq's
> habit of buffering the whole query result.  It's possible that there's
> a memory leak in the -A path specifically, but nothing said so far
> provided any evidence for that.
>
> 			regards, tom lane
>   

So, is libpq always buffering the result? Thanks.
I thought psql buffers only because in its formatted output mode
it has to know the widest value for all the columns.

Then the SELECT INTO TEMP ; COPY TO STDOUT solution
I found is _the_ solution.

I guess then the libpq-based ODBC driver suffers
from the same problem? It certainly explains the
performance problems I observed: the server
finishes the query, the ODBC driver (or libpq underneath)
fetches all the records and the application receives
the first record after all these. Nice.

Best regards,
Zoltán Böszörményi