From: | "Lussier, Denis" <denisl(at)openscg(dot)com> |
---|---|
To: | 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-09-23 01:55:27 |
Message-ID: | CAHKhnVXnxjr0gOqQV-JkQTWuu=6d-iYXY0V9jXVDgSBE==ZBwQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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.
On Mon, Sep 22, 2014 at 8:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> John R Pierce <pierce(at)hogranch(dot)com> writes:
> > this still won't address the issue that the postgresql server itself
> > ALSO marshals the entire result set into ITS memory before sending it to
> > the client.
>
> If it actually did that, then there would be an issue ... but it never
> has, and very likely never will. The server sends rows on-the-fly as
> they're computed. That is indeed the very reason that client libraries
> tend to want to accumulate full resultsets: they're hiding that behavior
> from applications, so as to make it look like you get either an error or
> a full resultset, not some rows and then an error.
>
> regards, tom lane
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>
From | Date | Subject | |
---|---|---|---|
Next Message | stagirus | 2014-09-23 04:53:05 | Re: Patch to allow setting schema/search_path in the connectionURL |
Previous Message | Vitalii Tymchyshyn | 2014-09-23 01:39:42 | Re: Disk buffering of resultsets |