"First, you HAVE to run PG with -F - it is 10 times or more slower. "
WHOA! You really don't want to do this, as you have no claim of data integrity in this case. -F turns off the fsynch'ing of modified data files after the end of each transaction. If your system goes down, the database will be toast, guaranteed.
Now ... -F makes no difference for read-only selects, which form the vast majority of ACS queries. And the ACS does its inserts in transactions so the -F penalty is not nearly as bad as worst-case testing would imply.
So in practice -F is only going to slow up a running ACS installation by, oh, 10% or so? unless people are doing tons of forum postings, etc. Even then I bet it won't be as much as you fear.
A better approach to speed things up is to move index files to another disk drive. Currently this really sucks in PG because you need to move the files by hand and link to them in the database directory, but people are working on implementing a tablespace-like facility to manage such things from within PG. This wins for the same reason it wins with Oracle - it minimizes head travel. Even though hand-moving and hand-linking sucks, it doesn't suck nearly as bad as guaranteeing your database will be permanently hosed due to a crash with -F enabled.
And work is also underweigh to implement write-ahead logging in PG. This not only increases data integrity, but only the log will need to be fsynch'd at the end of transactions, rather than all datafiles modified by a transaction. Since rational people will put the write-ahead log on its own platter, this will be a quick operation because the log will be written sequentially and will be the only file open on the drive.
Of cousre, if you do nightly dumps and are perfectly comfortable with the high probability that you'll probably have to roll back to one of the dumps eventually, the use of -F is just fine.
But, if you're doing financial transactions or keeping data you don't want to roll back to a nightly backup, you certainly don't want to do this.
