From: | <andrew(at)pricecomparison(dot)com> |
---|---|
To: | <pgsql-performance(at)postgresql(dot)org> |
Subject: | UNSUBSCRIBE |
Date: | 2007-01-11 00:49:33 |
Message-ID: | 001601c7351a$5c593340$6801a8c0@andrew |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
----- Original Message -----
From: "Jim C. Nasby" <jim(at)nasby(dot)net>
To: "Bob Dusek" <bob(at)copienttech(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)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(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)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2007-01-11 01:23:55 | Re: table partioning performance |
Previous Message | Scott Marlowe | 2007-01-10 21:51:55 | Re: Partitioning |