If we would change these then it would be Java or C. But all the heavy stuff is handled by Stored Procedures so I dont see a real need for a change.
I actually am more interested to hear if there are an recommended systems or setups.
Also with regard to 2/4 CPUs or 32/64 bit etc.
Scott Marlowe wrote:
On Thu, 2004-12-16 at 06:39, Michael Ben-Nes wrote:
I think and please correct me that Postgres loves RAM, the more the better.
Any way RAID5 is awful with writing, go with RAID1 ( mirroring )
With battery backed cache and a large array, RAID 5 is quite fast, even with writes. Plus with a lot of drives in a mostly read environment, it's quite likely that each read will hit a different drive so that many parallel requests can be handled quite well. The general rule I use is 6 or fewer drives will do better in RAID 1+0, 7 or more will tend to do better with RAID 5.
Perl is very slow, maybe you can use PHP ?
While mod_perl and its relations have never been fast running under
apache in comparison to PHP, it's no slouch, paying mostly in startup
time, not run time. For complex apps, the startup time difference
becomes noise compared to the run time, so it's no big advantage to
PHP. I really like PHP by the way. But Perl is pretty nice too.
Run the Unix OS you're most comfortable with, knowing that PostgreSQL gets lots of testing on the free unixes more so than on the commercial ones. Give it a machine with plenty of RAM and a fast I/O subsystem, and two CPUS and you'll get good performance. If your needs exceed the performance of one of these machines, you're probably better off going to a pgpool / slony cluster than trying to build a bigger machine.
---------------------------(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
