> 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-disk RAID-1 for RH Linux 8. My database has over
60 million records averaging 200 bytes per tuple. I have a large nightly data load,
then very complex multi-table join queries all day with a few INSERT transactions.
While I do not have 1000 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
with only two processors. Someday, if you can determine with certainty that the CPU
is a bottleneck, drop in the 3rd and 4th processors (and $10,000). And save yourself
money on the RAM as well - it's incredibly easy to put in more if you need 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 migrated from Microsoft SQL Server. Out of the box
PostgreSQL was horrible for me, and even after significant tuning it crawled on
certain queries (compared to MSSQL). The list helped me find a data type mismatch in
a JOIN clause, and since then the performance of PostgreSQL has blown the doors off of
MSSQL. Since I only gave myself a couple days to do tuning before the db had to go in
production, I almost had to abandon PostgreSQL and revert to MS. My problems were
solved in 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.
---------------------------(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
