Josh,
Thanks for your feedback, I appreciate it.
>Check what I have to say at http://www.powerpostgresql.com/PerfList
>
>
Will do.
>>They're currently on a two-disk Adaptec RAID1 with Postgresql 7.4.2.
>>
>>
>
>And you've not upgraded to 7.4.6 because .... ?
>
>
>
Because the proprietary application running the business has not
certified on it. Unfortunately, I am at the mercy of their support in
case something goes wrong.
>>The drive array is a 7-disk fibre channel on a Qlogic 2100 controller. I
>>am currently testing RAID5 (sw).
>>
>>
>
>In general, RAID 5 is not so great for databases. See the article for more.
>
>
>
Okay, thanks. Even with 7-disks? I trust that. So, RAID 1+0 (sw) is
probably the best option. I've run sw RAID personally for years without
issue. I am a bit hesitant in doing sw RAID for a production server for
a database --- probably because its not my server. Any thoughts on sw
RAID for Postgresql?
>>The main reason of moving to a drive array is the high level of context
>>switches we get during the day (>30K for 20 mins per hour). The OS and
>>database exist on the same disk but seperate parition (which probably
>>makes little difference)
>>
>>
>
>Unfortunately, the context switches are probably due to a known issue in
>PostgreSQL, and changing the drive array won't help this issue (it may help
>other issues though). Search the archives of this list, and pgsql-hackers,
>for "Context Switch Bug".
>
>For the CS bug, the only workaround right now is to avoid the query structures
>that trigger it.
>
>
Okay. Darn. While I don't write the queries for the application, I do
interact with the company frequently. Their considering moving the
queries into the database with PL/pgSQL. Currently their queries are
done through ProvIV development using ODBC. Will context switching be
minimized here by using PL/pgSQL?
>
>
>>Server Info:
>>Centos 3.3 (RHEL 3.x equivelent)
>>4GB RAM
>>Adaptec 2100S RAID
>>Qlogic QLA2100 Fibre
>>
>>
>
>CPU?
>
>
Dual Xeon 2.8 CPUs with HT turned off.
Thanks again.
Steve Poe