> > > "anonymous mapped memory" site:microsoft.com turns out 0 (zero)
> > > results. And even splitting it up there seems to be nearly no
> > > information ... is the same thing by any chance also known by
> > > different names?
> >
> > Hmm. Yeah, most likely :) I may have grabbed that name from
> something
> > else. THe documentation for the call is on
> >
> http://windowssdk.msdn.microsoft.com/en-us/library/ms685007(VS.80).asp
> > x, we specify INVALID_HANDLE_VALUE for hFile, which means:
>
> [...]
> CreateFileMapping creates a file mapping object of a
> specified size that _the operating system paging file backs_ [...]
>
> I assume that DWORD dwMaximumSizeHigh and DWORD
> dwMaximumSizeLow get filled with whatever I configure in
> shared_memory?
Yes. See the code in src/backend/port/win32 for details ;)
> My reading of that function gives me the impression, that
> this kind of shared *memory* is essentially a shared disk
> file - "_the operating system paging file backs_"
Yes. Note that this does *not* mean that it actually stores anything in
the file. All it means that *if* windows needs to *page out* this data,
it will do so to the pagefile, so the pagefile has to have enough room
for it. With a normal file, it would be paged out to the file instead of
the pagefile. But as long as there is enough free memory around, it will
stay in RAM.
If a specific part of shared memory (the mmaped pagefile) is not
accessed in a long time, it will get swapped out to the pagefile, yes.
And I don't beleive there is a way to make that not happen.
> Especially documentation lines like "If an application
> specifies a size for the file mapping object that is larger
> than the size of the actual named file on disk, the file on
> disk is increased to match the specified size of the file
> mapping object."
This is irrelevant, because we are not mapping a file.
> really makes me think that that area is just a comfortable
> way to access files on disk as memory areas; with the hope of
> propably better caching then not-memory-mapped files.
That shows that you don't really know how the memory manager in NT+
works ;-) *ALL* normal file I/O is handled through the memory manager
:-) So yes, they are both different access methods to the memory
manager, really.
> That would explain my disturbing impressions of performance
> of PostgreSQL on win32 rising when lowering shared_memory...
Not exactly. I can still see such a thing happening in some cases, but
not because all our shared memory actually hit disks. We'd be *dead* on
performance if it did.
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
