Re: maintenance_work_mem memory constraint?

From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: maintenance_work_mem memory constraint?
Date: 2007-11-26 20:41:33
Message-ID: 286CEB235CBD42AD0EFC2557@imhotep.credativ.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

--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.

--
Thanks

Bernd

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brendan Jurd 2007-11-26 20:42:21 Re: [GENERAL] Empty arrays with ARRAY[]
Previous Message Peter Eisentraut 2007-11-26 20:15:27 Re: Locating sharedir in PostgreSQL on Windows