Bruce Momjian wrote:
>
> > Can you make the size of the result set above which diskfiles will be used
> > configurable? That way ppl with loads of RAM can use huge buffers, and ppl
> > with little RAM can keep that RAM free for other processes.
>
> If I need a configuration value, I will either determine the amount of
> RAM portably, or base the value on the number of shared buffers
> requested with -B.
Why don't use additional flag as it suggested by Mark ?
Using -B is not good: the size of shared memory segment may be
limited by OS (under FreeBSD 2.1.0 it's limited to 4M) or system
administrator and so backend will use 2-4 M of RAM for sort on
box with 192 M RAM ?
This flag may be useful for joinpath.c:EnoughMemoryForHashjoin() too...
Also note that following
> - make psort read directly from the executor node below it
> (instead of an input relation)
it will be impossible to know the size of result before sort startup.
So you have to use palloc up to in-memory limit and switch to
'tape' files dynamically.
Also
> - makes the Sort node read directly from the last set of psort runs
> (instead of an output relation)
require changes to ExecSortMarkPos()/ExecSortRestrPos() which
use heap_markpos()/heap_restrpos() (because of last set of
psort is not normal heap relation).
But both changes of nodeSort.c are what we really need.
Vadim
------------------------------
