Skip site navigation (1) Skip section navigation (2)

performance implications of binary placement

From: "Bob Dusek" <bob(at)copienttech(dot)com>
To: <pgsql-performance(at)postgresql(dot)org>
Subject: performance implications of binary placement
Date: 2006-12-26 20:37:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
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

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

Note:  the only differences are that "Scenario 1" includes these

--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

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

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

Thanks again,



pgsql-performance by date

Next:From: Kevin HunterDate: 2006-12-26 22:29:58
Subject: Re: [NOVICE] Partitioning
Previous:From: Tom LaneDate: 2006-12-26 19:55:37
Subject: Re: Partitioning

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group