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 07D3952824 for ; Thu, 9 Jun 2005 09:25:35 -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 55746-05 for ; Thu, 9 Jun 2005 12:25:24 +0000 (GMT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by svr1.postgresql.org (Postfix) with ESMTP id 21B8D52881 for ; Thu, 9 Jun 2005 09:25:21 -0300 (ADT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DgLn6-0003GO-PF for pgsql-sql@postgresql.org; Thu, 09 Jun 2005 14:05:44 +0200 Received: from gateway.mgm-edv.de ([212.18.1.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Jun 2005 14:05:44 +0200 Received: from spam_eater by gateway.mgm-edv.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Jun 2005 14:05:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-sql@postgresql.org From: Thomas Kellerer Subject: Re: SELECT very slow Date: Thu, 09 Jun 2005 13:30:08 +0200 Lines: 23 Message-ID: References: <27961.1118275606@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: gateway.mgm-edv.de User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.7.6) Gecko/20050319 Mnenhy/0.7.2.0 X-Accept-Language: de, de-at, en-us, en In-Reply-To: <27961.1118275606@sss.pgh.pa.us> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.194 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200506/137 X-Sequence-Number: 21738 On 09.06.2005 02:06 Tom Lane wrote: > Thomas Kellerer writes: > >>Is there anything I can do, to convince PG to return the first row more >>quickly? > > The solution is to use a cursor and FETCH a reasonably small number of > rows at a time. Thanks for all your answers. I turned out that I did not read the JDBC documentation closely enough (blush) Setting the fetchSize to 1 (or something >0) only uses a cursor if autocommit is disabled (due to the annoying "transaction is aborted" when running DDL scripts that have errors, I usually turn autocommit on). With autocommit off, the rows will be returned "immediately" (so the driver is using a cursor to fetch the data) Regards Thomas