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

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

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: John R Pierce <pierce(at)hogranch(dot)com>
Cc: Neil Conway <neilc(at)samurai(dot)com>,Denis Vlasenko <vda(at)ilport(dot)com(dot)ua>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1756: PQexec eats huge amounts of memory
Date: 2005-07-07 17:43:57
Message-ID: 20050707174357.GD10035@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-bugs
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.)

-- 
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
Officer Krupke, what are we to do?
Gee, officer Krupke, Krup you! (West Side Story, "Gee, Officer Krupke")

In response to

Responses

pgsql-bugs by date

Next:From: Matthew T. O'ConnorDate: 2005-07-07 20:23:04
Subject: Re: pg_autovacuum: short, wide tables
Previous:From: mark reidDate: 2005-07-07 17:33:11
Subject: pg_autovacuum: short, wide tables

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