Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 00EBD9F9ED7 for ; Fri, 15 Dec 2006 20:07:11 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-new, port 10024) with ESMTP id 59092-03 for ; Fri, 15 Dec 2006 20:07:02 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by postgresql.org (Postfix) with ESMTP id C04529F9357 for ; Fri, 15 Dec 2006 20:07:06 -0400 (AST) Received: from osgiliath.mathom.us ([71.246.251.8]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JAC00B5LAZOR9V3@vms044.mailsrvcs.net> for pgsql-performance@postgresql.org; Fri, 15 Dec 2006 18:07:00 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by osgiliath.mathom.us (Postfix) with ESMTP id 787516EA76 for ; Fri, 15 Dec 2006 19:06:59 -0500 (EST) Received: from osgiliath.mathom.us ([127.0.0.1]) by localhost (osgiliath.home.mathom.us [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eZxnbTKJlHoK for ; Fri, 15 Dec 2006 19:06:57 -0500 (EST) Received: by osgiliath.mathom.us (Postfix, from userid 1000) id 487F670B38; Fri, 15 Dec 2006 19:06:57 -0500 (EST) Date: Fri, 15 Dec 2006 19:06:56 -0500 From: Michael Stone Subject: Re: New to PostgreSQL, performance considerations In-reply-to: To: pgsql-performance@postgresql.org Mail-followup-to: pgsql-performance@postgresql.org Message-id: <20061216000655.GI29167@mathom.us> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-disposition: inline X-Virus-Scanned: Debian amavisd-new at mathom.us X-Pgp-Fingerprint: 53 FF 38 00 E7 DD 0A 9C 84 52 84 C5 EE DF 7C 88 References: <09D6591B-4AA9-4994-BED6-0C7C583BF933@purefiction.net> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/431 X-Sequence-Number: 22487 On Fri, Dec 15, 2006 at 12:24:46PM -0500, Ron wrote: >ATM, the most we can say is that in a number of systems with modest >physical IO subsystems So I reran it on a 3.2GHz xeon with 6G RAM off a ramdisk; I/O ain't the bottleneck on that one. Results didn't show didn't show any signficant gains regardless of compilation options (results hovered around 12k tps). If people want to continue this, I will point out that they should make sure they're linked against the optimized libpq rather than an existing one elsewhere in the library path. Beyond that, I'm done with this thread. Maybe there are some gains to be found somewhere, but the testing done thus far (while limited) is sufficient, IMO, to demonstrate that compiler options aren't going to provide a blow-your-socks-off dramatic performance improvement. Mike Stone