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