X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 9D78311F6621 for ; Wed, 29 Mar 2006 07:40:46 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 02553-08 for ; Wed, 29 Mar 2006 07:40:46 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from peufeu.com (boutiquenumerique.com [82.67.9.10]) by postgresql.org (Postfix) with ESMTP id 1163011F661A for ; Wed, 29 Mar 2006 07:40:43 -0400 (AST) Received: (qmail 23356 invoked from network); 29 Mar 2006 13:40:55 +0200 Received: from boutiquenumerique.com (HELO apollo13) (82.67.9.10) by boutiquenumerique.com with SMTP; 29 Mar 2006 13:40:55 +0200 Date: Wed, 29 Mar 2006 13:40:54 +0200 To: "Greg Quinn" , pgsql-performance@postgresql.org Subject: Re: Slow performance on Windows .NET and OleDb References: <000d01c65261$19a3fa40$0200a8c0@pta.homex.co.za> <20060328173213.GO75181@pervasive.com> <442977D7.5060508@commandprompt.com> <006c01c652f9$1ca9c420$0200a8c0@pta.homex.co.za> <000f01c6531f$fcbc0570$0200a8c0@pta.homex.co.za> From: PFC Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <000f01c6531f$fcbc0570$0200a8c0@pta.homex.co.za> User-Agent: Opera M2/8.51 (Linux, build 1462) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.113 required=5 tests=[AWL=0.113] X-Spam-Score: 0.113 X-Spam-Level: X-Archive-Number: 200603/580 X-Sequence-Number: 18017 > 3000 Rows - 7 seconds - very slow On my PC (athlon 64 3000+ running Linux), selecting 3000 rows with 4 columns out of a 29 column table takes about 105 ms, including time to transfer the results and convert them to native Python objects. It takes about 85 ms on a test table with only those 4 columns. There is definitely a problem somewhere on your system. I'd suggest running this query in an infinite loop. Logically, it should use 100% processor, with postgres using some percentage (30% here) and your client using some other percentage (70% here). Is your processor used to the max ?