Description:
------------
We're migrating to PHP5 (v5.2.6) and have found that we are hitting the PHP memory limit on our new server. At the moment our code is the same as it was on our PHP4 server which had the same memory limit configured. I've included a snippet of SQL which, according to memory_get_usage, seems to consume 6MB of memory when it is run & the data set is retrieved into an array. The query only returns 3113 rows, and the columns are small (the largest is a c8; the smallest is a c1; there is also an i4 in the mix). The OpenAPI logs seem to suggest that the DBMS is returning roughly the amount of data that we would expect, so it seems to be an Ingres driver / PHP5 problem.

We use a wrapper script which opens a connection, fires off the SQL, uses a loop with ingres_fetch_array to pull out the data and then commits the transaction & closes the connection. This procedure occurs in full every time a query is executed from one of our PHP pages.

I'll be asking our SAs to upgrade to driver v2.0.2, and we may be able to up our memory limit, but it'd be good to find out why we've seen this hike in memory usage and if there is anything we can do to minimise it (e.g. lowering the size of the buffer).

Reproduce code:
---------------
SELECT s.ukc as sort, bm.ukc, bm.module_code, bm.module_version, bm.student_module_stage,
ifnull(cmd.credit_amount, '') as credit_amount, bm.pass_method, bm.stage_module_taken, 'N' as historic
FROM module m, module_details md, w_example s
WHERE s.ukc = bm.ukc
AND (md.module_code = m.module_code
AND md.module_version = m.module_version)
UNION 
SELECT s2.ukc as sort, hm.ukc, hm.module_code, hm.module_version, hm.student_module_stage, 
ifnull(cmd2.credit_amount, '') as credit_amount, '' as pass_method, hm.stage_module_taken, 'Y' as historic
FROM h_module hm, c_module_details md2, w_example_2 s2
WHERE s2.ukc = hm.ukc
AND trim(hm.student_module_stage) != ''
AND (md2.module_code = hm.module_code
AND md2.module_version = hm.module_version)
ORDER BY sort, student_module_stage, module_code, module_version, historic

Expected result:
----------------
We expect it to return ~3k rows without eating lots of memory. The total number of bytes represented by the columns being selected is less than 50; even if there is a very significant overhead incurred when storing the results, the result set should surely not occupy more than a few hundred kilobytes at most, let alone several megabytes!

Actual result:
--------------
memory_get_usage() reports that memory usage has jumped by about 6 megabytes during the execution of the query & retrieval of the results.