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
>
>