Re: Moving from 32 to 64 bit builds on Solaris - Mailing list pgsql-general

From Martijn van Oosterhout
Subject Re: Moving from 32 to 64 bit builds on Solaris
Date
Msg-id 20070310184730.GA25096@svana.org
Whole thread Raw
In response to Re: Moving from 32 to 64 bit builds on Solaris  (Dan Sugalski <dan@sidhe.org>)
Responses Re: Moving from 32 to 64 bit builds on Solaris  (Dan Sugalski <dan@sidhe.org>)
List pgsql-general
On Sat, Mar 10, 2007 at 08:30:20AM -0500, Dan Sugalski wrote:
> Possibly it won't. The machine the DB is on sees heavy access to
> large files, to the point where parts of the database may get flushed
> out of the OS buffer cache. I was working on the (possibly deeply
> flawed assumption) that I'd be better off if more of the database was
> guaranteed pinned in memory in Postgres' buffer cache -- it wouldn't

Err, is shared memory actually guarenteed to be pinned in memory? I
mean, in Linux it's not as that is a form of DOS attack, pin all memory
by allocating it as SHM.

Now, Solaris may do this differently, but if shared memory can be
swapped out then having lots of it definitly isn't a beniefit.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Attachment

pgsql-general by date:

Previous
From: Christian Schröder
Date:
Subject: How to enforce uniqueness when NULL values are present?
Next
From: "David Legault"
Date:
Subject: Re: HIPPA (was Re: Anyone know ...)