At 09:30 PM 2/13/2004 -0800, Dann Corbit wrote:
> Well, unless the Postgres cache is more efficient than the OS's, no?. > You could then use the nocache filesystem option, and just > let Postgres handle the whole thing. Of course, that's a > pretty big unless, and not one that I'm volunteering to make go away!
Most database systems I have tried scale very well with increased memory. For instance, Oracle, and SQL*Server will definitely benefit greatly by adding more memory. I suspect (therefore) that there must be some way to squeeze some benefit out of it.
Yeah, but if the O/S cache etc also scales well with increased memory it may not make enough difference to make it worth the effort. Might be similar to the raw disk/partition thing - sure it's faster initially, but there's probably better bang for the buck elsewhere, and what happens if you change storage hardware - arrays, etc?
Unlike the Oracle etc, it doesn't seem as strategic for Postgresql to compete with the O/S makers, and try to replace various parts of the O/S. It makes sense for Oracle, coz they can charge more, plus if the O/S sucks, their stuff runs better than the other competing DBs on the same O/S.
However in this day and age, I'd rather pick a better O/S - and when the O/S improves, your DB seamlessly gains. So you might as well make sure the DB is really good at working with the O/S. You probably don't want cases where the entire DB is in mem, and a single select has the system 50% idle waiting for dunno what.
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
