Re: setFetchSize() [Viruschecked]
| От | Patric Bechtel |
|---|---|
| Тема | Re: setFetchSize() [Viruschecked] |
| Дата | |
| Msg-id | 20030717171322.C9CAECCA46@svr1.postgresql.org обсуждение исходный текст |
| Ответ на | Re: setFetchSize() (Dmitry Tkach <dmitry@openratings.com>) |
| Ответы |
Re: setFetchSize() [Viruschecked]
|
| Список | pgsql-jdbc |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 17 Jul 2003 13:01:43 -0400, Dmitry Tkach wrote:
Hello Dmitry,
that's exactly what the driver is doing if you do a setFetchSize(10).
Nevertheless, it won't solve the problem of the server eating HUGE amounts of memory if you do a "declare foo cursor
forselect * from myhugetable". It seems
like postgresql locks all rows (or even copies them around in memory) until the connection drops again.
Patric
>Rich Cullingford wrote:
>> All,
>> Will this function be implemented in Release 7.4? I have several arge
>> tables that run Java out of memory when I attempt to load them through
>> JDBC. Any workarounds arppreciated...
>I was using cursors for a while as a workaround...
>Something like this:
>c.setAutocommit (false);
>Statement s = c.createStatement ();
>s.execute ("declare foo cursor for select * from bar");
>while (true)
>{
> ResultSet rs = s.executeQuery ("fetch 10 from foo");
> int count = 0;
> while (rs.next ())
> {
> count++;
> doStuffWithThisRow (rs);
> }
>
> if (count < 10) //The whole cursor contents has been processed
> break;
>}
>
>
>I hope, it helps...
>Dima
>---------------------------(end of broadcast)---------------------------
>TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
PGP Public Key Fingerprint: 2636 F26E F523 7D62 4377 D206 7C68 06BB
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1 (C) 1997-1999 Network Associates, Inc. and its affiliated companies.
iQA/AwUBPxbKwXxoBrvMu8qQEQKC8gCfWN0mM5HfiheSggCracN3JPglHckAn0KI
G5m+Vo0NZQ9l53pE44U9EpyK
=udRs
-----END PGP SIGNATURE-----
В списке pgsql-jdbc по дате отправления: