Re: Compile Vs RPMs

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Christopher Browne <cbbrowne(at)libertyrms(dot)info>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Compile Vs RPMs
Date: 2004-02-04 16:24:57
Message-ID: Pine.LNX.4.33.0402040920190.28468-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, 3 Feb 2004, Christopher Browne wrote:

> adave(at)vantage(dot)com ("Anjan Dave") writes:
> > I would like to know whether there are any significant performance
> > advantages of compiling (say, 7.4) on your platform (being RH7.3, 8,
> > and 9.0, and Fedora especially) versus getting the relevant binaries
> > (rpm) from the postgresql site? Hardware is Intel XEON (various
> > speeds, upto 2.8GHz, single/dual/quad configuration).
>
> Some Linux distribution makers make grand claims of such advantages,
> but it is not evident that this is much better than superstition.
>
> You are certainly NOT going to see GCC generating MMX code
> automagically that would lead to PostgreSQL becoming 8 times faster.
>
> Indeed, in database work, it is quite likely that you will find things
> to be largely I/O bound, with CPU usage being a very much secondary
> factor.
>
> I did some relative benchmarking between compiling PostgreSQL on GCC
> versus IBM's PPC compilers a while back; did not see differences that
> could be _clearly_ discerned as separate from "observational noise."
>
> You should expect find that adding RAM, or adding a better disk
> controller would provide discernable differences in performance. It
> is much less clear that custom compiling will have any substantial
> effect on I/O-bound processing.

I would add that the primary reason for compiling versus using RPMs is to
take advantage of some compile time option having to do with block size,
or using a patch to try and test a system that has found a new corner case
where postgresql is having issues performing well, like the vacuum page
delay patch for fixing the issue with disk bandwidth saturation. If
you've got a machine grinding to its knees under certain loads, and have a
test box to test it on, and the test box shows better performance, it
might be better to patch the live server on the off hours if it will keep
the thing up and running during the day.

In that way, performance differences are very real, but because you are
doing something you can't do with factory rpms. Of course, building
custom rpms isn't that hard to do, so if you had a lot of boxes that
needed a patched flavor of postgresql, you could still run from rpms and
have the custom patch.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jan Wieck 2004-02-04 21:54:06 Re: [PERFORM] MySQL+InnoDB vs. PostgreSQL test?
Previous Message Mike Nolan 2004-02-04 13:36:43 Re: [PERFORM] MySQL+InnoDB vs. PostgreSQL test?