Re: [PERFORM] psql -A (unaligned format) eats too much
От | Andrew Dunstan |
---|---|
Тема | Re: [PERFORM] psql -A (unaligned format) eats too much |
Дата | |
Msg-id | 44845E86.3080001@dunslane.net обсуждение исходный текст |
Ответ на | Re: [PERFORM] psql -A (unaligned format) eats too much ("Mark Woodward" <pgsql@mohawksoft.com>) |
Ответы |
Re: [PERFORM] psql -A (unaligned format) eats too much
Re: [PERFORM] psql -A (unaligned format) eats too much |
Список | pgsql-hackers |
Mark Woodward wrote: >> "Jim C. Nasby" <jnasby@pervasive.com> 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
В списке pgsql-hackers по дате отправления: