On Sun, 22 Jun 1997, Bruce Momjian wrote:
> > Why use shared memory for this? Why not use mmap() for it? Come
> > to think of it, mmap()'ng it would have better scalability, no? If you
> > already know the result size (ie. 256k), you could that have the code try
> > to mmap() that amount of memory to do the sort in. If the mmap() fails,
> > revert to using a file...now the result size of the SELECT doesn't have a
> > compiled in "limit" to the size of memory used for the sort...its restricted
> > to the amount of memory on the machine (ie. if I double the RAM, I should be
> > able to have double the results sorted in memory instead of one disk)
>
> I don't think we need mmap() because we never need to put it on disk.
> Just palloc() the memory.
okay, I'm not totally familiary with palloc()...I did a project while
back where we mmap()'d a region of memory so that we didn't need to write
to disk. Essentially, I used ftruncate() to create the size of the buffer I
wanted to mmap(), and never flushed the memory...
Not sure what palloc() does though...should look into it, eh? :(
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
------------------------------
