From: | "Dann Corbit" <DCorbit(at)connx(dot)com> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Quad Xeon vs. Dual Itanium |
Date: | 2004-02-14 05:30:27 |
Message-ID: | D90A5A6C612A39408103E6ECDD77B8299CA7D7@voyager.corporate.connx.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> -----Original Message-----
> From: Andrew Sullivan [mailto:ajs(at)crankycanuck(dot)ca]
> Sent: Friday, February 13, 2004 9:05 PM
> To: pgsql-general(at)postgresql(dot)org
> Subject: Re: [GENERAL] Quad Xeon vs. Dual Itanium
>
>
> On Fri, Feb 13, 2004 at 10:46:18PM -0500, Tom Lane wrote:
>
> > Quite honestly, I suspect we may be wasting our time hacking the
> > Postgres buffer replacement algorithm at all. There are a bunch of
> > reasons why the PG shared buffer arena should never be more than a
> > small fraction of physical RAM, and under those conditions
> the cache
> > replacement algorithm that will matter is the kernel's, not ours.
>
> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Browne | 2004-02-14 13:41:52 | Re: Quad Xeon vs. Dual Itanium |
Previous Message | Andrew Sullivan | 2004-02-14 05:05:26 | Re: Quad Xeon vs. Dual Itanium |