Received: from localhost (maia-5.hub.org [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id 37A019F9F2C
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 26 Dec 2006 16:55:42 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024)
	with ESMTP id 23703-04 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 26 Dec 2006 16:55:27 -0400 (AST)
X-Greylist: delayed 00:27:55.976282 by SQLgrey-1.7.4
Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159])
	by postgresql.org (Postfix) with ESMTP id 9F9559FA49D
	for <pgsql-performance@postgresql.org>;
	Tue, 26 Dec 2006 16:55:29 -0400 (AST)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.3
Received: from mail01.copienttech.com (pluto.copienttech.com [72.12.217.18])
	by svr4.postgresql.org (Postfix) with ESMTP id 51AD65AF044
	for <pgsql-performance@postgresql.org>;
	Tue, 26 Dec 2006 20:27:33 +0000 (GMT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
Subject: performance implications of binary placement 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 26 Dec 2006 15:37:47 -0500
Message-ID: <1F3542D36E2E6C4780CDA3AC0102BF7006A807@mail01.copienttech.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: performance implications of binary placement 
Thread-Index: AccpLEAbPEIjutjLQfSae1GXv1rH9g==
From: "Bob Dusek" <bob@copienttech.com>
To: <pgsql-performance@postgresql.org>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=BAYES_50
X-Spam-Level: 
X-Archive-Number: 200612/527
X-Sequence-Number: 22583

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=3D/usr --libdir=3D/usr/lib --bindir=3D/usr/bin
--includedir=3D/usr/include/pgsql --datadir=3D/usr/share/postgresql
--mandir=3D/usr/share/man --with-docdir=3D/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=3D/usr --libdir=3D/usr/lib --bindir=3D/usr/bin
--includedir=3D/usr/include/pgsql --datadir=3D/usr/share/postgresql
--mandir=3D/usr/share/man --with-docdir=3D/usr/share/doc/packages

And, to be clear, "Scenario 1" performs worse than "Scenario 2".  Simple
insert statements are taking significantly longer.=20

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.=20

Has anyone seen this before?  Are hard drive mechanics the only thing in
play here?   =20

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.=20

Thanks for any help you can provide.  I can provide more detail if
needed.

Thanks again,

Bob=20