My experience has been that RAID5 + Postgres = counter productive. I've
been happier with a 4-way software mirror (Linux).
In the past, Postgres has been very drive seek intensive, because of the
way index scans were performed. RAID5 does *NOTHING* to help this. Raw
disk throughput is essentially a non-issue with Postgres, for the sort
of use I'm used to putting it to.
My tests have shown *HUGE* improvement in index scans in 8.1. The
bitmap index read was one of the most profound improvements I've seen in
Postgres yet. I suspect 8.1 would help you quite a lot.
-Glen
Joseph Shraibman wrote:
I'm running 8.0.8 on a raid 5 over 13 disks, and select performance on a
query that needs to join two large tables is very bad. top shows pg
using 2 to 4 percent cpu. Doing a query on one big table uses 30 to 45
percent cpu.
This is RHEL 4 running kernel 2.6.9-22.ELsmp, using an LSI fiber channel
adapter. The disk shelf is one of these:
http://iqstor.com/products/iq1000.htm
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
