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

Re: performance implications of binary placement

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: Bob Dusek <bob(at)copienttech(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: performance implications of binary placement
Date: 2007-01-10 20:01:15
Message-ID: 20070110200115.GP12217@nasby.net (view raw or flat)
Thread:
Lists: pgsql-performance
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(at)postgresql(dot)org so that your
>        message can get through to the mailing list cleanly
> 

-- 
Jim Nasby                                            jim(at)nasby(dot)net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

In response to

Responses

pgsql-performance by date

Next:From: Jim C. NasbyDate: 2007-01-10 20:07:54
Subject: Re: More 8.2 client issues (Was: [Slow dump?)
Previous:From: Jeremy HaileDate: 2007-01-10 19:26:55
Subject: Re: Slow inner join, but left join is fast

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