> > > "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
