X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 8B7389FA3A6 for ; Wed, 10 May 2006 20:07:53 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 44893-08 for ; Wed, 10 May 2006 20:07:48 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from h57078.serverkompetenz.net (talk-net.net [81.169.128.8]) by postgresql.org (Postfix) with ESMTP id 5C6BD9F931E for ; Wed, 10 May 2006 20:07:48 -0300 (ADT) Received: from [192.168.115.250] (e178173057.adsl.alicedsl.de [85.178.173.57]) by h57078.serverkompetenz.net (Postfix) with ESMTP id 6873A50C533; Thu, 11 May 2006 01:06:07 +0200 (CEST) Message-ID: <44627250.5010908@network-inventory.de> Date: Thu, 11 May 2006 01:08:00 +0200 From: Thomas Vatter User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Jurka CC: Scott Marlowe , Tino Wildenhain , pgsql-performance@postgresql.org Subject: Re: in memory views References: <4461AFFF.7060200@network-inventory.de> <4461B3DE.6030700@wildenhain.de> <4461B899.4030502@network-inventory.de> <1147273917.9755.22.camel@state.g2switchworks.com> <4462098D.2010500@network-inventory.de> <1147275906.9755.25.camel@state.g2switchworks.com> <446252E8.8000304@network-inventory.de> <1147294882.9755.55.camel@state.g2switchworks.com> <44625A1B.7080809@network-inventory.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/281 X-Sequence-Number: 19068 Kris Jurka wrote: > > > On Wed, 10 May 2006, Thomas Vatter wrote: > >> Yes, the difference between psql command line and application is 6 >> seconds to 40 seconds. It is exactly the step resultSet = >> excecuteQuery() that needs 40 seconds. I use next() as a cursor >> through the resultSet, but I fear this is not enough, do I have to >> use createStatement(resultSetType, resultSetConcurrency) respectively >> prepareStatement (resultSetType, resultSetConcurrency) to achieve the >> cursor behaviour? > > > http://jdbc.postgresql.org/documentation/81/query.html#query-with-cursor > > Kris Jurka I was just returning to my mailbox to report success, I was just a bit faster than your e-mail, I have found the fetchSize function, it reduces the delay to 6 seconds. thanks a lot to all who helped, this was really great support, I am glad that the problem is solved tom