On Tue, 2003-02-11 at 12:49, Merlin Moncure wrote: > Does anyone know whether cygwin has a setting comparable to SHMMAX, > and if so what is its default value? How about the upcoming native > Windows port --- any issues there? > > >From a pure win32 point of view, a good approach would be to use the > VirtualAlloc() memory allocation functions and set up a paged memory > allocation system. From a very top down point of view, this is the > method of choice if portability is not an issue. An abstraction to use > this technique within pg context is probably complex and requires > writing lots of win32 api code, which is obviously not desirable. > > Another way of looking at it is memory mapped files. This probably most > closely resembles unix shared memory and is the de facto standard way > for interprocess memory block sharing. Sadly, performance will suffer > because you have to rely on the virtual memory system (think: writing to > files) to do a lot of stupid stuff you don't necessarily want or need. > The OS has to guarantee that the memory can be swapped out to file at > any time and therefore mirrors the pagefile to the allocated memory > blocks. > > With the C++/C memory malloc/free api, you are supposed to be able to > get some of the benefits of virtual alloc (in particular, setting a > process memory allocation limit), but personal experience did not bear > this out. However, this api sits directly over the virtual allocation > system and is the most portable. The application has to guard against > fragmentation and things like that in this case. In win32, server > thrashing is public enemy #1 for database servers, mostly due to the > virtual allocation system (which is quite fast when used right, btw).
IIRC, there is a mechanism which enables it to be directly supported/mapped via pagefile. This is the preferred means of memory mapped files unless you have a specific need which dictates otherwise. Meaning, it allows for many supposed optimizations to be used by the OS as it is suppose to bypass some of the filesystem overhead. Regards, -- Greg Copeland <[EMAIL PROTECTED]> Copeland Computer Consulting ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
