Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

Next:From: Kris JurkaDate: 2005-07-18 21:08:04
Subject: Re: BUG #1756: PQexec eats huge amounts of memory
Previous:From: Kevin GrittnerDate: 2005-07-18 20:18:04
Subject: Re: BUG #1756: PQexec eats huge amounts of memory

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group