| From: | "Matt Magoffin" <postgresql(dot)org(at)msqr(dot)us> |
|---|---|
| To: | "Stephen Frost" <sfrost(at)snowman(dot)net> |
| Cc: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>, "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:01:37 |
| Message-ID: | 49522.192.168.1.106.1234213297.squirrel@msqr.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> 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?
Regards,
Matt
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2009-02-09 21:03:07 | Re: Out of memory on SELECT in 8.3.5 |
| Previous Message | Matt Magoffin | 2009-02-09 20:58:00 | Re: Out of memory on SELECT in 8.3.5 |