From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Matt Magoffin <postgresql(dot)org(at)msqr(dot)us> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Out of memory on SELECT in 8.3.5 |
Date: | 2009-02-09 21:32:27 |
Message-ID: | dcc563d10902091332p72841379r8d1d06fbc558810f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Feb 9, 2009 at 2:01 PM, Matt Magoffin <postgresql(dot)org(at)msqr(dot)us> wrote:
>> I don't think changing work_mem down is actually going to reduce the
>> memory allocated without changing the plan to something less optimal.
>> In the end, all of this is putting off the inevitable, if you get enough
>> PGs going and enough requests and whatnot, you're going to start running
>> out of memory again. Same if you get larger data sets that take up more
>> hash table space or similar. Eventually you might need a bigger box,
>> but let's try to get everything in the current box to at least be used
>> first..
>
> Yes... and indeed changing vm.overcommit_ratio to 80 does allow that
> previously-failing query to execute successfully. Do you think this is
> also what caused the out-of-memory error we saw today just when a
> transaction was initiated?
Curious, what's the explain analyze look like for that one?
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2009-02-09 21:35:20 | Re: Out of memory on SELECT in 8.3.5 |
Previous Message | SHARMILA JOTHIRAJAH | 2009-02-09 21:23:10 | ora2pg or dbi_link ? |