Re: maintenance_work_mem memory constraint? - Mailing list pgsql-hackers

From Bernd Helmle
Subject Re: maintenance_work_mem memory constraint?
Date
Msg-id ECF17CC91872BBAD6349FCC5@imhotep.credativ.de
Whole thread Raw
In response to Re: maintenance_work_mem memory constraint?  (Bernd Helmle <mailings@oopsware.de>)
List pgsql-hackers
--On Montag, November 26, 2007 21:41:33 +0100 I wrote:

> --On Montag, November 26, 2007 13:02:14 -0500 Tom Lane
> <tgl@sss.pgh.pa.us> wrote:
>
>> Bernd Helmle <mailings@oopsware.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


pgsql-hackers by date:

Previous
From:
Date:
Subject: Re: Replacement Selection
Next
From: sulfinu@gmail.com
Date:
Subject: String encoding during connection "handshake"