From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | "Lussier, Denis" <denisl(at)openscg(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | John R Pierce <pierce(at)hogranch(dot)com>, List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Disk buffering of resultsets |
Date: | 2014-10-04 14:44:36 |
Message-ID: | 543007D4.6070109@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On 09/23/2014 09:55 AM, Lussier, Denis wrote:
> Wow... really glad Tom chimed in on this. I've been promoting/using
> PG as an enterprise-class database for over a decade and I was
> struggling with the "fact" that the server doesn't iterate thru a cursor
> without bringing it all into memory.
Well, that assertion would've failed the common-sense sanity test anyway.
You can `SELECT * FROM my_100GB_table` on a machine with 1GB of RAM.
Clearly this is impossible if Pg must marshal all the results into RAM
first.
I think John's misapprehension probably stemmed from the fact that libpq
and many other clients *default* to fetching the whole result from the
server into RAM before reporting success to the caller. This makes it
*seem* like the server must marshal the whole result in memory, but it's
the client doing that, not the server.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2014-10-04 14:56:38 | Re: Disk buffering of resultsets |
Previous Message | Craig Ringer | 2014-10-04 14:42:13 | Re: Disk buffering of resultsets |