Re: setFetchSize [Viruschecked] - Mailing list pgsql-jdbc

From Felipe Schnack
Subject Re: setFetchSize [Viruschecked]
Date
Msg-id 20030717111733.4aa10020.felipes@ritterdosreis.br
Whole thread Raw
In response to Re: setFetchSize [Viruschecked]  ("Patric Bechtel" <bechtel@ipcon.de>)
Responses Re: setFetchSize [Viruschecked]
List pgsql-jdbc
Hi Patric!
  hm... would be nice if this patch of yours were in the current driver... you submitted it to the maintainers?
  I actually don't understand why the default behaviour is to fetch all data, seems crazy to me :-)

On Thu, 17 Jul 2003 16:12:32 +0200
"Patric Bechtel" <bechtel@ipcon.de> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, 17 Jul 2003 09:31:45 -0400, Fernando Nasser wrote:
>
> >Felipe Schnack wrote:
> >>   There is a way that I can set setFetchSize() that will prevent pgsql from caching all the results of a query to
server'smemory? 
> >>   I'm trying to search in the archives but any search I try returns 0 results...
> >>
>
> >Have you tried setting it to a positive value and turning off autocommit
> >(you must be inside a transaction to do this)?
>
> Hello Felipe,
>
> nice to see that there's another one who has the same problem than me (although if would be nicer if we both wouldn't
;-)).
> I've an application using Castor (maybe hibernate, in a later version), but SOME queries tend to produce huge result
sets,as though directly after transferring to  
> the 'client' (which in this case is the app server), can be forgotten at all. But postgres seems to hold this query
inone of the front ends, though. This happens  
> in the moment I use setFetchSize() (I've a patched postgres driver which can do this via the URL), the server starts
eatingmemory like nuts. 
> In one case, a rather trivial query with very many rows even broke the backend completely, as after 1.5 GB there was
noRAM available anymore. It looked like This  
> one backend process which grew then is not shrinking anymore (at least no significantly), and I can only get rid of
itby closing the connection; this one isn't  
> trivial, as I'm using a connection pool.
> But I need the connection pool, as without this, Castor as well as Hibernate are incredibly slow; for each
transactionthey open a connection, do what ever is  
> needed, commit or rollback, and close the connection. And even IF they wouldn't, it would be a problem, though.
> Is there anything one can do to use server side cursors AND having the postgres server using a reasonable amount of
memory?
> BTW: I can reproduce this behaviour in psql, too, so it's not really a problem of the JDBC driver itself. But I've
foundno discussion on GENERAL of HACKERS about  
> that, too.
>
> tia
>
> Patric
>
> 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/AwUBPxagwXxoBrvMu8qQEQJsjwCdE1e3GHFgBGZegw9w0bfxrgjDrPcAn1yV
> Xt75aWxAuBqDijvPET2v2v4b
> =1OFf
> -----END PGP SIGNATURE-----
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>                http://archives.postgresql.org


--

 /~\ The ASCII        Felipe Schnack (felipes@ritterdosreis.br)
 \ / Ribbon Campaign  Analista de Sistemas
  X  Against HTML     Cel.: 51-91287530
 / \ Email!           Linux Counter #281893

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter@ritterdosreis.br
Fone: 51-32303341

pgsql-jdbc by date:

Previous
From: "Patric Bechtel"
Date:
Subject: Re: setFetchSize [Viruschecked]
Next
From: Kim Ho
Date:
Subject: Fix for using JDK1.2 instead of JDK1.4 method in date/time/timestampToString