Steve,
> 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.
FWIW, 7.4.6 is a binary, drop-in place upgrade for 7.4.2. And 7.4.2 has known
bugs. However, I understand your situation.
> Okay, thanks. Even with 7-disks? I trust that.
Well, it's less bad with 7 disks than it is with 3, certainly. However,there
is an obvious and quick gain to be had by splitting off the WAL logs onto
their own disk resource ... up to 14%+ performance in some applications.
> 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?
Yes. See my article for one. In generaly, SW RAID on BSD or Linux works
well for PostgreSQL ... UNLESS your machine is already CPU-bound, in which
case it's a bad idea. If you're hitting the CS bug, it's definitely a bad
idea, because the SW RAID will increase context switching.
So if your choice, on your system, is between sw RAID 10, and hw RAID 5, and
you're having excessive CSes, I'd stick with the HW RAID.
> 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?
Won't make a difference, actually. Should improve performance in other ways,
though, by reducing round-trip time on procedures. Feel free to recommend
the company to this list.
> Dual Xeon 2.8 CPUs with HT turned off.
Yeah, thought it was a Xeon.
--
Josh Berkus
Aglio Database Solutions
San Francisco
