Shridhar Daithankar <[EMAIL PROTECTED]> writes: > If the parent postmaster mmaps anonymous memory segments and shares them with > children, postgresql wouldn't be dependent upon any kernel resourse aka > shared memory anymore.
Anonymous memory mappings aren't shared, at least not unless you're talking about creating posix threads. That's just not how you create shared mappings using mmap. There is a way to create shared mappings using mmap, but it's exactly what you say you don't want to do -- you use file mappings. Using mmap postgres could allocate as much shared memory as it needs whenever it needs it. You create a file the size of the mapping you want, you mmap it with MAP_SHARED, then you arrange to have any other backends that want access to it to mmap it as well. I'm not sure why you say you don't want to map files. If you're afraid it will cause lots of i/o as the system tries to flush these writes, well, in theory that's up to the kernel to avoid. On systems where the kernel does poorly at this there are tools like MAP_LOCK/mlock/shmfs that might trick it into doing a better job. Actually I've been wondering how hard it would be to avoid this whole double-buffering issue and having postgres mmap the buffers it wants from the data files. That would avoid the double-buffering entirely including the extra copy and memory use. But it would be a major change to a lot of core stuff. And it be tricky to ensure WAL buffers are written before data blocks. -- greg ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match