Обсуждение: Prepared Statement Memory Size

We have a prepared statement example below:



Query = SELECT consumer.consumer_id, consumer.address, consumer.operator_id

FROM consumer

INNER JOIN registration_list_consumer AS rlc ON (consumer.consumer_id =
rlc.consumer_id AND rlc.registration_list_id = 15)

INNER JOIN registration_list as rl on (rl.registration_list_id =
rlc.registration_list_id  AND rl.status_id = 25  )

WHERE  consumer.address_type_id IN (1)

AND  NOT EXISTS (SELECT 'x' FROM target_run_transaction trt

WHERE consumer.consumer_id = trt.consumer_id AND trt.target_run_id = 468)
AND  NOT EXISTS (SELECT 'x' FROM registration_list_consumer AS rlc_exclude,
registration_list rl WHERE rlc_exclude.registration_list_id =
rl.registration_list_id AND rlc_exclude.consumer_id = consumer.consumer_id
AND rl.status_id = 25

AND rlc_exclude.registration_list_id in (34))  ORDER BY RANDOM() LIMIT 788



With no dynamic parameters populated during runtime�it will return roughly
1million rows. During execution of the query the preparedStatment grows in
size up to 80MB and beyond.



We have the fetchSize set to 1000

And autocommit set to false.



And the following params set�



stmt =
conn.prepareStatement(query,ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY);



can you suggest a work around to fix this problem�why is it taking up so
much memory?



Thanks,

jennie

On Tue, 18 Jul 2006, jennie browne wrote:

> We have a prepared statement example below:
>
> With no dynamic parameters populated during runtime it will return
> roughly 1million rows. During execution of the query the
> preparedStatment grows in size up to 80MB and beyond.
>
> We have the fetchSize set to 1000
> And autocommit set to false.
>
> And the following params set
>
> stmt =
> conn.prepareStatement(query,ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY);
>

setFetchSize will only work with ResultSet.TYPE_FORWARD_ONLY.  It has no
effect on scrollable ResultSets.

Kris Jurka

Jennie,

You say it returns a million rows, but you have a limit of 788 ?? How
is that possible.

What version of postgres, and driver are you using ?

Dave
On 18-Jul-06, at 12:42 PM, jennie browne wrote:

> We have a prepared statement example below:
>
>
>
> Query = SELECT consumer.consumer_id, consumer.address,
> consumer.operator_id
>
> FROM consumer
>
> INNER JOIN registration_list_consumer AS rlc ON
> (consumer.consumer_id = rlc.consumer_id AND
> rlc.registration_list_id = 15)
>
> INNER JOIN registration_list as rl on (rl.registration_list_id =
> rlc.registration_list_id  AND rl.status_id = 25  )
>
> WHERE  consumer.address_type_id IN (1)
>
> AND  NOT EXISTS (SELECT 'x' FROM target_run_transaction trt
>
> WHERE consumer.consumer_id = trt.consumer_id AND trt.target_run_id
> = 468)  AND  NOT EXISTS (SELECT 'x' FROM registration_list_consumer
> AS rlc_exclude, registration_list rl WHERE
> rlc_exclude.registration_list_id = rl.registration_list_id AND
> rlc_exclude.consumer_id = consumer.consumer_id AND rl.status_id = 25
>
> AND rlc_exclude.registration_list_id in (34))  ORDER BY RANDOM()
> LIMIT 788
>
>
>
> With no dynamic parameters populated during runtime
> it will return roughly 1million rows. During execution of the query
> the preparedStatment grows in size up to 80MB and beyond.
>
>
>
> We have the fetchSize set to 1000
>
> And autocommit set to false.
>
>
>
> And the following params set
>
>
>
>
> stmt = conn.prepareStatement
> (query,ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY);
>
>
>
> can you suggest a work around to fix this problem
> why is it taking up so much memory?
>
>
>
> Thanks,
>
> jennie
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>