Thread: performance implications of binary placement
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
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)
----- Original Message ----- From: "Jim C. Nasby" <jim@nasby.net> To: "Bob Dusek" <bob@copienttech.com> Cc: <pgsql-performance@postgresql.org> 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