Prev: [HACKERS] Hot Standby performance and deadlocking
Next: [HACKERS] [PATCH] Add XMLEXISTS function from the SQL/XML standard (was: Addxpath_exists Function)
From: Andrew Dunstan on 25 May 2010 10:47 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 26 May 2010 09:34
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 |