Performance questions are terrible to answer because
we all use our systems in different ways. Here's my
2 bits for what they're worth.
> The idea behind the first is to keep the
> entire database in memory, by way of the disk cache.
What you describe is a real-time system. Does your
requirements call for real-time performance ?
Remember that performance from memory is much more
expensive than disk i/o (at least up to a certain point).
> A web interface allows people to accept, or (usually)
> discard the trapped messages.
IMHO this means no real-time.
> So, most data is write once, read at most once, delete.
This is not exactly an optimum case for caching. I would
suggest thinking really hard before going for an all memory
solution. From what you write I would suggest a firm focus
on disc i/o.
But in the end the best person to ask really is yourself.
How is the system loaded ? Is disk i/o maxed out ?
Are the cpu's overload'ed ? Is it paging like cracy ?
I suggest looking at your current bottleneck first.
It's likely to be the most cost-efficient route out.
Could also be some magic pg tunning tricks out there
you've missed. Who knows. I spent two weeks on google
and tuning last year with amazing results.
Also remember that pg collects performance statistics.
Those will help a lot in finding out what's really
going on. This can also reveal where the database is
being used inefficient by the application, missing
index'es etc.
At present I'm running a 130gig base on a 4gig mem
four way 6650 with an external (fiber channel) raid
5 box.
I admit the load is not that terrible or time sensitive
(web self-service) but the performance is still pretty
hot. The requests are very scattered so i/o is key. My
cache benefit is mostly from the index's.
Good luck in your quest for "bang per buck" ;-)
Cheers,
John