Re: maintenance_work_mem memory constraint?

--On Montag, November 26, 2007 21:41:33 +0100 I wrote:

> --On Montag, November 26, 2007 13:02:14 -0500 Tom Lane
> <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Bernd Helmle <mailings(at)oopsware(dot)de> writes:
>>> ... But isn't it worth to special case the
>>> code in grow_memtuples() (and maybe other places where sort is likely to
>>> use more RAM), so that we can remove this constraint on 64-Bit systems
>>> with many RAM built in? Or am I missing something very important?.
>>
>> AFAICS this patch can increase the number of sortable tuples by at most
>> 2X (less one). That doesn't seem worth getting very worked up about ...
>>
>> regards, tom lane
>
> That's true.
>
> Well, i haven't meant the diff as a discussable patch at all. It's just
> what i've done to understand why we have this limit for tuplesort.
> afaics, the main constraint here is MaxAllocSize, and i just wonder if
> that doesn't introduce unnecessary limits on systems which can use many
> RAM for index creation and wether we can be more generous here. So one
> idea could be to allow larger allocation requests during sorting on
> systems where we know that this is likely to work.

And, to complete my concerns, if i can afford to give maintenance_work_mem
10GB and the system just uses 2GB this is somewhere near a bug.

--
Thanks

Bernd