On Tuesday 11 November 2003 00:50, Neil Conway wrote:Jan Wieck <[EMAIL PROTECTED]> writes: > We can't resize shared memory because we allocate the whole thing in > one big hump - which causes the shmmax problem BTW. If we allocate > that in chunks of multiple blocks, we only have to give it a total > maximum size to get the hash tables and other stuff right from the > beginning. But the vast majority of memory, the buffers themself, can > be made adjustable at runtime.
Yeah, writing a palloc()-style wrapper over shm has been suggested before (by myself among others). You could do the shm allocation in fixed-size blocks (say, 1 MB each), and then do our own memory management to allocate and release smaller chunks of shm when requested. I'm not sure what it really buys us, though: sure, we can expand the shared buffer area to some degree, but
Thinking of it, it can be put as follows. Postgresql needs shared memory between all the backends.
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.
And how does a newly mmap'ed segment propagate into a running backend?
Jan
Furthermore parent posmaster can allocate different anonymous mappings for different databases. In addition to postgresql buffer manager overhaul, this would make things lot better.
note that I am not suggesting mmap to maintain files on disk. So I guess that should be OK.
I tried searching for mmap on hackers. The threads seem to be very old. One in 1998. with so many proposals of rewriting core stuff, does this have any chance?
Just a thought.
Shridhar
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(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
