Re: Experimental patch for inter-page delay in VACUUM

On Tuesday 11 November 2003 00:50, Neil Conway wrote:
> Jan Wieck <JanWieck@Yahoo.com> 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.

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