On Fri, Feb 09, 2007 at 09:49:25AM -0500, Tom Lane wrote:
> "Takayuki Tsunakawa" <tsunakawa.takay@jp.fujitsu.com> writes:
> > I wonder whether the field you are talking about set Windows to use
> > more memory for programs than for filesystem cache, which is
> > selectable from [System] applet of Control Panel (Oh, I wonder how my
> > machine is set in this respect... have to check.) If filesystem cache
> > is preferred, the following senario may be possible:
>
> > 1. PostgreSQL tries to read data from disk into database cache.
> > 2. The kernel tries to allocate filesystem buffers by paging out
> > PostgreSQL's memory (possibly shared buffers).
> > 3. PostgreSQL finds data requested by its clients in database cache,
> > and tries to get it in memory.
> > 4. But the shared buffers are paged out, and page-ins happen.
>
> It's certainly true that if shared_buffers is large enough to make the
> kernel try to swap out parts of the shared buffer array, then you've got
> a counterproductive situation resulting in net *more* I/O than if you'd
> used a smaller setting. On some Unixen shared memory is implicitly
> locked in RAM, and on others it's possible to request locking it (though
> I'm not sure we try to at the moment). Perhaps it's always swappable on
> Windows? Or maybe Windows is just more eager to swap it out?
The way it is it is definitly always swappable. I've been thinking of
digging into that, but haven't had the time. There are API calls to mark
memory as non-swappable, but I'm not sure it works on shared memory the
way we do it.
Apart from saying that, I will refrain from speculatnig more in *why*
it's slower with more shared memory before someone (yeah, I realise that
could be me) does some actual investigation into what happens.
//Magnus