X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id ACE479FA5B5 for ; Mon, 5 Jun 2006 13:41:23 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 37638-06 for ; Mon, 5 Jun 2006 13:41:13 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from trolak.mydnsbox2.com (ns1.mydnsbox2.com [207.44.142.118]) by postgresql.org (Postfix) with ESMTP id 5A9889FA30C for ; Mon, 5 Jun 2006 13:41:12 -0300 (ADT) Received: from [192.168.1.227] (68.143.134.146.nw.nuvox.net [68.143.134.146]) (authenticated (0 bits)) by trolak.mydnsbox2.com (8.11.6/8.11.6) with ESMTP id k55G4Cc18211; Mon, 5 Jun 2006 11:04:12 -0500 Message-ID: <44845E86.3080001@dunslane.net> Date: Mon, 05 Jun 2006 12:40:38 -0400 From: Andrew Dunstan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060201 SeaMonkey/1.0 MIME-Version: 1.0 To: Mark Woodward CC: Tom Lane , "Jim C. Nasby" , Zoltan Boszormenyi , 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> <20060605155349.GU53487@pervasive.com> <20813.1149523235@sss.pgh.pa.us> <18006.24.91.171.78.1149526092.squirrel@mail.mohawksoft.com> In-Reply-To: <18006.24.91.171.78.1149526092.squirrel@mail.mohawksoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/162 X-Sequence-Number: 84395 Mark Woodward wrote: >> "Jim C. Nasby" writes: >> >>> On Mon, Jun 05, 2006 at 11:27:30AM -0400, Tom Lane wrote: >>> >>>> 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. >>>> >>> Certainly seems like it. It seems like it would be good to allow for >>> libpq not to buffer, since there's cases where it's not needed... >>> >> See past discussions. The problem is that libpq's API says that when it >> hands you back the completed query result, the command is complete and >> guaranteed not to fail later. A streaming interface could not make that >> guarantee, so it's not a transparent substitution. >> >> I wouldn't have any strong objection to providing a separate API that >> operates in a streaming fashion, but defining it is something no one's >> bothered to do yet. In practice, if you have to code to a variant API, >> it's not that much more trouble to use a cursor... >> >> > > Wouldn't the "COPY (select ...) TO STDOUT" format being discussed solve > this for free? > > > It won't solve it in the general case for clients that expect a result set. ISTM that "use a cursor" is a perfectly reasonable answer, though. cheers andrew