Re: BUG #1756: PQexec eats huge amounts of memory - Mailing list pgsql-bugs

From Denis Vlasenko
Subject Re: BUG #1756: PQexec eats huge amounts of memory
Date
Msg-id 200507101305.10878.vda@ilport.com.ua
Whole thread Raw
In response to Re: BUG #1756: PQexec eats huge amounts of memory  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-bugs
On Thursday 07 July 2005 20:43, Alvaro Herrera wrote:
> On Thu, Jul 07, 2005 at 08:17:23AM -0700, John R Pierce wrote:
> > Neil Conway wrote:
> > >Denis Vlasenko wrote:
> > >
> > >>The same php script but done against Oracle does not have this
> > >>behaviour.
> > >
> > >
> > >Perhaps; presumably Oracle is essentially creating a cursor for you
> > >behind the scenes. libpq does not attempt to do this automatically; if
> > >you need a cursor, you can create one by hand.
> >
> > I do not understand how a cursor could be autocreated by a query like
> >
> >     $result = pg_query($db, "SELECT * FROM big_table");
> >
> > php will expect $result to contain the entire table (yuck!).
>
> Really?  I thought what really happened is you had to get the results
> one at a time using the pg_fetch family of functions.  If that is true,
> then it's possible to make the driver fake having the whole table by
> using a cursor.  (Even if PHP doesn't do it, it's possible for OCI to do
> it behind the scenes.)

Even without cursor, result can be read incrementally.

I mean, query result is transferred over network, right?
We just can stop read()'ing before we reached the end of result set,
and continue at pg_fetch as needed.

This way server does not need to do any of cursor
creation/destruction work. Not a big win, but combined with
reduced memory usage at client side, it is a win-win situation.
--
vda

pgsql-bugs by date:

Previous
From: Oliver Jowett
Date:
Subject: Re: BUG #1756: PQexec eats huge amounts of memory
Next
From: rmkml
Date:
Subject: Freebsd and postgresql 748: pg_dump compile error