X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 3BCE152809 for ; Wed, 15 Jun 2005 19:10:21 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 11198-04 for ; Wed, 15 Jun 2005 22:10:18 +0000 (GMT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by svr1.postgresql.org (Postfix) with ESMTP id 043F65284D for ; Wed, 15 Jun 2005 19:10:16 -0300 (ADT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Difzi-00023Z-UP for pgsql-sql@postgresql.org; Thu, 16 Jun 2005 00:04:22 +0200 Received: from ppp-82-135-64-131.mnet-online.de ([82.135.64.131]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Jun 2005 00:04:22 +0200 Received: from spam_eater by ppp-82-135-64-131.mnet-online.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Jun 2005 00:04:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-sql@postgresql.org From: Thomas Kellerer Subject: Re: SELECT very slow Date: Thu, 16 Jun 2005 00:08:18 +0200 Lines: 46 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ppp-82-135-64-131.mnet-online.de User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.7.6) Gecko/20050319 Mnenhy/0.6.0.104 X-Accept-Language: de, en In-Reply-To: X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200506/175 X-Sequence-Number: 21776 PFC wrote on 15.06.2005 22:04: > >> It's not the program or Java. The same program takes about 20 seconds >> with Firebird and the exactly same data. > > > Hm, that's still very slow (it should do it in a couple seconds like > my PC does... maybe the problem is common to postgres and firebird ?) > > Try eliminating disk IO by writing a set returning function which > returns 1000000 rows, something simple like just a sequence number and > a text value... if this is slow too... i don't know... > do you have an antivirus or zonealarm or something ? Wouldn't that affect all DB access not only PG? And as I said, all other The 20 seconds are ok. This includes processing of the data in the application. If I simply loop over the result set and get each column's value without further processing it takes 4 seconds with Firebird. Basically I'm doing the following: rs = stmt.executeQuery("select * from foo"); while (rs.next()) { for (int i=0; i < 4; i++) { Object o = rs.getObject(i+1); } } As I said in my other post, the behaviour/performance in PG is dependent on the autocommit setting for the connection. With autocommit set to false the above code takes about 3 seconds in PG but wit autocommit set to true, PG takes 3 minutes! It seems that it also is very dependent on the fetchsize (apparently the number of rows that are cached by the driver). Anything above 100 seems to slow down the overall process. Regards Thomas