Re: High volume inserts - more disks or more CPUs? - Mailing list pgsql-general

From Lincoln Yeoh
Subject Re: High volume inserts - more disks or more CPUs?
Date
Msg-id 5.2.1.1.1.20041213171532.02c538b8@localhost
Whole thread Raw
In response to High volume inserts - more disks or more CPUs?  ("Guy Rouillier" <guyr@masergy.com>)
List 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=======--


pgsql-general by date:

Previous
From: Janning Vygen
Date:
Subject: Re: table with sort_key without gaps
Next
From: Michael Fuhr
Date:
Subject: Re: Substring question