From: Andrew Dunstan on


Alex Goncharov wrote:
> ,--- I/Alex (Mon, 24 May 2010 12:25:18 -0400) ----*
> | No equivalent of FETCH_COUNT is available at the libpq level, so I
> | assume that the interface I am using is smart enough not to send
> | gigabytes of data to FE.
> |
> | Where does the result set (GBs of data) reside after I call
> | PQexecPrepared? On BE, I hope?
>
> Sorry for asking again...
>
> No sarcasm meant: is there no straightforward answer here? Or nobody
> is certain? Or a wrong list?
>
>
>

You have been given the answer. Please re-read the replies, e.g. the one
from Abhijit Menon-Sen.

The data is saved on the client side before the call returns. If that
uses too much memory, use a cursor.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Giles Lean on

Abhijit Menon-Sen <ams(a)toroid.org> wrote:

> Unless you explicitly declare and fetch from an SQL-level cursor, your
> many GBs of data are going to be transmitted to libpq, which will eat
> lots of memory. (The wire protocol does have something like cursors,
> but libpq does not use them, it retrieves the entire result set.)

Sounds like a project. Anyone got any suggestions about
semantics and function names? (Assuming that this can be done
without causing more problems on the backend; I'd rather one
frontend client get messed up than mess up the server if
someone makes a query like that.)

I'm not exactly volunteering to work on something like this
(my TODO list is a trifle long) but I'm working on a native Go
language interface for PostgreSQL presently (influced by but
not an exact clone of libpq) so it's perhaps something I could
do if I get free time in future.

Giles

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers