From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | vda(at)ilport(dot)com(dot)ua, alvherre(at)alvh(dot)no-ip(dot)org, pierce(at)hogranch(dot)com, pgsql-bugs(at)postgresql(dot)org, neilc(at)samurai(dot)com |
Subject: | Re: BUG #1756: PQexec eats huge amounts of memory |
Date: | 2005-07-18 20:25:40 |
Message-ID: | 16737.1121718340@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Are you saying that if I execute a statement like:
> select * from "TableWithHundredsOfMillionsOfRows"
> that the entire table will be copied to a result set before returning
> the first row?
libpq does things that way, yes.
> Is this result set built in RAM on the server side?
No.
> I am interested primarily in the behavior under JDBC, although psql is
> also significant.
JDBC does things its own way; I believe it is possible to fetch a
resultset in a streaming fashion in JDBC, but you'd have to ask them.
The point of this discussion is simply that the current libpq API does
not permit streaming resultsets. This is not a limitation of the
server, nor of the protocol, nor even really of libpq itself if you
were willing to invent a suitable new set of API definitions for a
streaming-resultset interface. But we aren't going to change the
existing API to do streaming behind the client's back, because it won't
be transparent.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2005-07-18 21:08:04 | Re: BUG #1756: PQexec eats huge amounts of memory |
Previous Message | Kevin Grittner | 2005-07-18 20:18:04 | Re: BUG #1756: PQexec eats huge amounts of memory |