Re: [PERFORM] Compile Vs RPMs

2004-02-04 Thread scott.marlowe
On Tue, 3 Feb 2004, Christopher Browne wrote:

 [EMAIL PROTECTED] (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.  




---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PERFORM] Compile Vs RPMs

2004-02-03 Thread Bill Moran
Anjan Dave wrote:
Hello,
 
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).
significant is a relative term.  1% can be significant under the proper
circumstances ...
http://www.potentialtech.com/wmoran/source.php

The information isn't specific to Postgres, and the results aren't really
conclusive, but hopefully it helps.
I really think that if someone would actually test this with Postgres and
post the results, it would be very beneficial to the community.  I have
it on my list of things to do, but it's unlikely to get done in the first
quarter the way things are going.
--
Bill Moran
Potential Technologies
http://www.potentialtech.com
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [PERFORM] Compile Vs RPMs

2004-02-03 Thread Paul Thomas
On 03/02/2004 20:58 Anjan Dave wrote:
Hello,

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).
Very unlikely I would have thought. Databases tend to speed-limited by I-O 
performance and the amount of RAM available for caching etc. Having said 
that, I've only got one machine (the laptop on which I'm writing this 
email) which has still got its rpm binaries. My other machines have all 
been upgraded from source.

--
Paul Thomas
+--+-+
| Thomas Micro Systems Limited | Software Solutions for the Smaller 
Business |
| Computer Consultants | 
http://www.thomas-micro-systems-ltd.co.uk   |
+--+-+

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [PERFORM] Compile Vs RPMs

2004-02-03 Thread Christopher Browne
[EMAIL PROTECTED] (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.
-- 
output = reverse(ofni.smrytrebil @ enworbbc)
http://dev6.int.libertyrms.com/
Christopher Browne
(416) 646 3304 x124 (land)

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match