From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Dan Sugalski <dan(at)sidhe(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Moving from 32 to 64 bit builds on Solaris |
Date: | 2007-03-10 18:47:30 |
Message-ID: | 20070310184730.GA25096@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | David Legault | 2007-03-10 19:01:17 | Re: HIPPA (was Re: Anyone know ...) |
Previous Message | Christian Schröder | 2007-03-10 18:15:45 | How to enforce uniqueness when NULL values are present? |