Skip site navigation (1) Skip section navigation (2)

Re: [PERFORM] psql -A (unaligned format) eats too much

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Mark Woodward <pgsql(at)mohawksoft(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Zoltan Boszormenyi <zboszor(at)dunaweb(dot)hu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PERFORM] psql -A (unaligned format) eats too much
Date: 2006-06-05 17:03:24
Message-ID: 448463DC.8030306@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
Mark Woodward wrote:
>>>>
>>>>
>>>>         
>>> 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.
>>     
>
> I'm not sure I agree -- surprise!
>
> psql is often used as a command line tool and using a cursor is not
> acceptable.
>
> Granted, with an unaligned output, perhaps psql should not buffer the
> WHOLE result at once, but without rewriting that behavior, a COPY from
> query may be close enough.
>
>   

You have missed my point. Surprise!

I didn't say it wasn't OK in the psql case, I said it wasn't helpful in 
the case of *other* libpq clients.

Expecting clients generally to split and interpret COPY output is not 
reasonable, but if they want large result sets they should use a cursor.

cheers

andrew


In response to

pgsql-performance by date

Next:From: Zoltan BoszormenyiDate: 2006-06-05 17:17:31
Subject: Re: [PERFORM] psql -A (unaligned format) eats too much
Previous:From: Mark WoodwardDate: 2006-06-05 17:01:45
Subject: Re: [PERFORM] psql -A (unaligned format) eats too much

pgsql-hackers by date

Next:From: Zoltan BoszormenyiDate: 2006-06-05 17:17:31
Subject: Re: [PERFORM] psql -A (unaligned format) eats too much
Previous:From: Mark WoodwardDate: 2006-06-05 17:01:45
Subject: Re: [PERFORM] psql -A (unaligned format) eats too much

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group