Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 7B0019FA473 for ; Wed, 10 Jan 2007 20:56:38 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-new, port 10024) with ESMTP id 18991-04 for ; Wed, 10 Jan 2007 20:56:23 -0400 (AST) X-Greylist: delayed 00:06:41.867747 by SQLgrey-1.7.4 Received: from pcvs1.pricecomparison.com (dsl093-029-002.hou1.dsl.speakeasy.net [66.93.29.2]) by postgresql.org (Postfix) with ESMTP id 611AE9FA2A7 for ; Wed, 10 Jan 2007 20:56:17 -0400 (AST) X-Spam-DCC: sonic.net: fw.pricecomparison.com 1156; Body=1 Fuz1=1 Fuz2=1 X-Envelope-From: andrew@pricecomparison.com Received: from pricecomparison.com ([192.168.1.15]) by fw (Copfilter 0.83beta3a) X-Copfilter: Client is part of local network Received: (qmail 95291 invoked from network); 10 Jan 2007 18:49:34 -0600 Received: from unknown (HELO andrew) (192.168.1.104) by 192.168.1.15 with SMTP; 10 Jan 2007 18:49:34 -0600 Message-ID: <001601c7351a$5c593340$6801a8c0@andrew> Reply-To: From: To: References: <1F3542D36E2E6C4780CDA3AC0102BF7006A807@mail01.copienttech.com> <20070110200115.GP12217@nasby.net> Subject: UNSUBSCRIBE Date: Wed, 10 Jan 2007 18:49:33 -0600 Organization: PriceComparison.com LLC MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Copfilter-Originating-IP: 192.168.1.15 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.097 tagged_above=0 required=5 tests=BAYES_50, FORGED_RCVD_HELO, NO_REAL_NAME X-Spam-Level: * X-Archive-Number: 200701/161 X-Sequence-Number: 22762 ----- Original Message ----- From: "Jim C. Nasby" To: "Bob Dusek" Cc: Sent: Wednesday, January 10, 2007 2:01 PM Subject: Re: [PERFORM] performance implications of binary placement > 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) > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org