On Sat, 2006-04-22 at 13:17 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > I still do, for multi-user systems. Releasing unused memory from a large
> > CREATE INDEX will allow that memory to be swapped out, even if the brk
> > point can't be changed.
>
> Say what? It can get "swapped out" anyway, whether we free() it or not.
Of course it can, but if the memory is not actively used by the sort
then it will be OK if that happens and fairly likely also. If we
actively use the memory for the sort it would is less likely to be
swapped out and a bad thing if it did.
> More to the point, though: I don't believe that the proposed patch is a
> good idea --- it does not reduce the peak sortmem use, which I think is
> the critical factor for a multiuser system,
I agree peak memory use is the critical factor. There is only one
performsort in progress at any one time, though there can be many final
merges/retrievals in progress concurrently. If the majority of the
memory used by performsoft is released afterwards then it can be made
available for subsequent sorts/hashes etc without increasing further the
peak mem use.
> and what it does do is
> reduce the locality of access to the sort temp file during the merge
> phases. That will definitely have some impact; maybe small, but some;
> and I don't see where the benefit comes in.
That I already accept.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com/
