Skip site navigation (1) Skip section navigation (2)

Re: Pgsql 7.4/8.0 on IA64 HP-UX 11i?

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 (view raw or flat)
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:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?admit=716493758+1096399563091+28353475&threadId=673998


In response to

pgsql-general by date

Next:From: Andre MaasikasDate: 2004-09-28 19:46:31
Subject: Re: Syntax Issue in Trigger Function??
Previous:From: Tom LaneDate: 2004-09-28 19:18:45
Subject: Re: Pgsql 7.4/8.0 on IA64 HP-UX 11i?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group