From: | Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> |
---|---|
To: | "Guy Rouillier" <guyr(at)masergy(dot)com>, "PostgreSQL General" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: High volume inserts - more disks or more CPUs? |
Date: | 2004-12-13 09:43:00 |
Message-ID: | 5.2.1.1.1.20041213171532.02c538b8@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
--=======174A76C=======
Content-Type: text/plain; x-avg-checked=avg-ok-15674D89; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit
At 12:16 AM 12/13/2004 -0600, Guy Rouillier wrote:
>(3) If we go with more disks, should we attempt to split tables and
>indexes onto different drives (i.e., tablespaces), or just put all the
>disks in hardware RAID5 and use a single tablespace?
Fast inserts = fast writes.
RAID5 = slower writes.
You may wish to consider mirroring and striping aka RAID10... With a 4 disk
array, reads could be 4X faster and writes could be 2X faster compared to
single disk (assuming decent RAID controllers or RAID software). For the
same number of disks, RAID5 would be slower than RAID10 but RAID5 will have
more storage capacity. RAID10 would have slightly better redundancy - if 2
out of 4 of the right disks fail, you could still have all your data :).
If the insert performance is more important then go for more disks over
more CPU.
If the read queries are more important than the insert performance AND the
queries are likely to fit within RAM, then more CPU could be better. If
you're not doing lots of fancy queries and the queries don't fit in 16GB,
then go for the 50% more disks (6 vs 4).
But I'm not a DB consultant ;).
Regards,
Link.
--=======174A76C=======--
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Wollny | 2004-12-13 09:48:23 | Re: High volume inserts - more disks or more CPUs? |
Previous Message | Richard Huxton | 2004-12-13 09:41:45 | Re: High volume inserts - more disks or more CPUs? |