From: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Pgsql 7.4/8.0 on IA64 HP-UX 11i? |
Date: | 2004-09-28 19:36:27 |
Message-ID: | 200409281336.27844.pgsql@bluepolka.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tuesday September 28 2004 1:18, Tom Lane wrote:
> "Ed L." <pgsql(at)bluepolka(dot)net> writes:
> >> I wouldn't panic. 99% of the value of a 64-bit box for database work
> >> is that you can handle more than 4Gb worth of RAM for disk cache.
> >> Since in Postgres's worldview most of the disk caching is supposed to
> >> be done by the kernel, it really matters not whether the Postgres
> >> executables think they are 32-bit or 64-bit. All you need is a 64-bit
> >> kernel.
> >
> > The HPUX gurus on http://forums1.itrc.hp.com testify that kernel caches
> > above approximately 600MB are counter-productive to performance.
>
> Why? And why would you think that whatever effect is limiting the
> performance would not also apply to Postgres?
Well, I'm hardly the guru here, but if I understood correctly, the
degradation is due to competition between vhand and the kernel buffer
cache, resulting in applications being unable to get needed memory back
from the kernel buffer cache in a timely fashion. Assuming it's
competition between the kernel buffer cache and vhand, it seems logical to
think that removing the buffer cache from the competition would allow pgsql
a free hand to manage its own, large cache free.
Here's a discussion link:
From | Date | Subject | |
---|---|---|---|
Next Message | Andre Maasikas | 2004-09-28 19:46:31 | Re: Syntax Issue in Trigger Function?? |
Previous Message | Tom Lane | 2004-09-28 19:18:45 | Re: Pgsql 7.4/8.0 on IA64 HP-UX 11i? |