| 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: | Whole Thread | Raw Message | 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 |