> Now, the second question is related to the performance of the database. Assuming we have a
> dell's poweredge 6650 with 4 x 2.8 Ghz Xeon processors having 2 MB of cache for each, with the
> main memory of lets say 32 GB. We can either use a small SAN from EMC or we can put all disks
> into the machines with the required raid confiuration.
>
> We will install RedHat Advanced Server 2.1 to the machine as the operating system and postgresql as
> the database server. We have a database having 25 millions records having the length of 250 bytes
> on average for each record. And there are 1000 operators accessing the database concurrently. The main
> operation on the database (about 95%) is select rather than insert, so do you have any idea about
> the performance of the system?
I have a very similar installation: Dell PE6600 with dual 2.0 Xeons/2MB cache, 4 GB memory, 6-disk RAID-10 for data,
2-diskRAID-1 for RH Linux 8. My database has over 60 million records averaging 200 bytes per tuple. I have a large
nightlydata load, then very complex multi-table join queries all day with a few INSERT transactions. While I do not
have1000 concurrent users (more like 30 for me), my processors and disks seem to be idle the vast majority of the time
-this machine is overkill. So I think you will have no problem with your hardware, and could probably easily get away
withonly two processors. Someday, if you can determine with certainty that the CPU is a bottleneck, drop in the 3rd
and4th processors (and $10,000). And save yourself money on the RAM as well - it's incredibly easy to put in more if
youneed it. If you really want to spend money, set up the fastest disk arrays you can imagine.
I cannot emphasize enough: allocate a big chunk of time for tuning your database and learning from this list. I
migratedfrom Microsoft SQL Server. Out of the box PostgreSQL was horrible for me, and even after significant tuning it
crawledon certain queries (compared to MSSQL). The list helped me find a data type mismatch in a JOIN clause, and
sincethen the performance of PostgreSQL has blown the doors off of MSSQL. Since I only gave myself a couple days to do
tuningbefore the db had to go in production, I almost had to abandon PostgreSQL and revert to MS. My problems were
solvedin the nick of time, but I really wish I had made more time for tuning.
Running strong in production for 7 months now with PostgreSQL 7.3, and eagerly awaiting 7.4!
Roman Fail
POS Portal, Inc.
