Re: BUG #1756: PQexec eats huge amounts of memory

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

Browse pgsql-bugs by date

  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