| From: | Giles Lean <giles(dot)lean(at)pobox(dot)com> |
|---|---|
| To: | Abhijit Menon-Sen <ams(at)toroid(dot)org> |
| Cc: | Alex Goncharov <alex-goncharov(at)comcast(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: libpq, PQexecPrepared, data size sent to FE vs. FETCH_COUNT |
| Date: | 2010-05-26 13:34:14 |
| Message-ID: | 20100526133414.5554.qmail@sapphire.netherstone.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Abhijit Menon-Sen <ams(at)toroid(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2010-05-26 13:37:47 | Re: Synchronization levels in SR |
| Previous Message | Simon Riggs | 2010-05-26 13:20:46 | Re: Synchronization levels in SR |