Re: using a lot of maintenance_work_mem

From: Jim Nasby <jim(at)nasby(dot)net>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Frederik Ramm <frederik(at)remote(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: using a lot of maintenance_work_mem
Date: 2011-04-15 02:18:57
Message-ID: 1D8EBB1E-3BBD-43AC-89B4-ACC15A016599@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Apr 9, 2011, at 9:23 PM, Stephen Frost wrote:
> Actually, Tom has a point in that work_mem can be set above 1GB (which
> is where I had it set previously..). I didn't think it'd actually do
> anything given the MaxAlloc limit, but suprisingly, it does (at least,
> under 8.4). I'm currently trying to see if we've got anything that's
> going to *break* with work_mem set up that high; right now I have a
> hashagg plan running across this data set which has 2.4G allocted to
> it so far.
>
> I'll update this thread with whatever I find out. I'm trying to
> remember the other issues that I ran in to with this limit (beyond the
> whole sort limit, which I do think would be helped by allowing a larger
> value, but it's not as big a deal).

FWIW, I regularly set maintenance_work_mem to 8G for index builds. Presumably that's equivalent to running a sort in a regular query with work_mem set that high...
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2011-04-15 02:56:10 Re: WIP: Allow SQL-language functions to reference parameters by parameter name
Previous Message Jim Nasby 2011-04-15 02:14:35 Re: Proposal for GSoC : ADJ dashboard (Administration related software)