> 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.
>
> Add a flag over top of that, like -B, that states the *max* result
> size to do an in-memory sort with...or, rather, the *max* to try to do one
> with.
>
> Marc G. Fournier
> Systems Administrator @ hub.org
> primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
>
>
- --
Bruce Momjian
maillist@candle.pha.pa.us
------------------------------
