Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 075679FB251 for ; Wed, 10 Jan 2007 16:01:31 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024) with ESMTP id 41967-07-3 for ; Wed, 10 Jan 2007 16:01:18 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 514429FB22E for ; Wed, 10 Jan 2007 16:01:18 -0400 (AST) Received: by noel.decibel.org (Postfix, from userid 1001) id 66D1956443; Wed, 10 Jan 2007 14:01:17 -0600 (CST) Received: (hashcash-sendmail, from uid 1001); Wed, 10 Jan 2007 14:01:15 -0600 Date: Wed, 10 Jan 2007 14:01:15 -0600 From: "Jim C. Nasby" To: Bob Dusek Cc: pgsql-performance@postgresql.org Subject: Re: performance implications of binary placement Message-ID: <20070110200115.GP12217@nasby.net> References: <1F3542D36E2E6C4780CDA3AC0102BF7006A807@mail01.copienttech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1F3542D36E2E6C4780CDA3AC0102BF7006A807@mail01.copienttech.com> X-Operating-System: FreeBSD 6.1-RELEASE-p10 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.13 (2006-08-11) X-Hashcash: 1:20:070110:bob@copienttech.com::lE3kLyYuhzPMkFa7:000000000000000000 0000000000000000000000000knQ X-Hashcash: 1:20:070110:pgsql-performance@postgresql.org::Vzv61JpPvLAV9N2l:00000 0000000000000000000000002IPL X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/140 X-Sequence-Number: 22741 Are you 100% certain that both builds are using all the same libraries? And to be an apples-apples comparison, you really need to ensure that the datadir is on the same filesystem in both cases (that's the first thing I'd check). Also, that pg_index... error sounds like the second build has been corrupted. On Tue, Dec 26, 2006 at 03:37:47PM -0500, Bob Dusek wrote: > Hello all, > > I've been running performance tests on various incantations of Postgres > on/off for a month or so. And, I've just come across some unexpected > results. > > When I start my Postgres build as such: > > # (Scenario 1) > > ./configure --prefix=/usr --libdir=/usr/lib --bindir=/usr/bin > --includedir=/usr/include/pgsql --datadir=/usr/share/postgresql > --mandir=/usr/share/man --with-docdir=/usr/share/doc/packages > --disable-rpath --enable-thread-safety --enable-integer-datetimes > --without-python --without-perl --without-tcl --without-tk > > It performs significantly worse than when I start my build like this: > > # (Scenario 2) > > ./configure --disable-rpath --enable-thread-safety > --enable-integer-datetimes --without-python --without-perl --without-tcl > --without-tk > > Note: the only differences are that "Scenario 1" includes these > options: > > --prefix=/usr --libdir=/usr/lib --bindir=/usr/bin > --includedir=/usr/include/pgsql --datadir=/usr/share/postgresql > --mandir=/usr/share/man --with-docdir=/usr/share/doc/packages > > And, to be clear, "Scenario 1" performs worse than "Scenario 2". Simple > insert statements are taking significantly longer. > > I did not expect to see a performance hit with these options, especially > since "/usr/" on the test machine is mounted as its own partition, and > in both cases, all of the binaries, include files, etc. are in that > partition. > > Has anyone seen this before? Are hard drive mechanics the only thing in > play here? > > The only difference I'm seeing in logging between the two versions is > that Scenario 2 has several of this message littered throughout the > logfile: > > ERROR: could not open relation "pg_index_indexrelid_index": No such file > or directory > > But, that doesn't seem to be effecting functionality or performance > (especially considering the fact that the logfile that contains that > message is part of the test that is performing better). > > We're using Postgres 7.4.8, building from the SLES9 Postgres 7.4.8 > source rpm. > > Thanks for any help you can provide. I can provide more detail if > needed. > > Thanks again, > > Bob > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)