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.
