| From: | scott ribe <scott_ribe(at)elevated-dev(dot)com> |
|---|---|
| To: | Davlet Panech <dpanech(at)gmail(dot)com> |
| Cc: | pgsql-admin(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Abnormally high memory usage/OOM triggered |
| Date: | 2018-01-18 17:34:59 |
| Message-ID: | 460E4952-3C5F-4A17-A426-09FD0249FF82@elevated-dev.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Jan 18, 2018, at 10:13 AM, Davlet Panech <dpanech(at)gmail(dot)com> wrote:
>
> On 1/17/2018 5:57 PM, scott ribe wrote:
>> On Jan 17, 2018, at 2:57 PM, Davlet Panech <dpanech(at)gmail(dot)com> wrote:
>>>
>>> Does my configuration look reasonable? I just don't understand how it could possibly use up 19 GB of memory based on the configuration below. Is there a memory leak in there somewhere?
>> It does seem awfully high, but... An update can involve a join across multiple tables. Or an update can run a trigger which can cascade. Either of those could result in an "accidental cross product" join, which can always blow up memory.
> There must be a way to put an upper limit on memory even for such cases. I was under the impression that parameters such as "work_mem" serve that purpose, is that not the case? So an "accidental cross product" join's memory usage is unbounded? It can't be... could somebody confirm this please?
You are correct as far as I know, so yeah, that case should result in filling disk, not RAM
--
Scott Ribe
https://www.linkedin.com/in/scottribe/
(303) 722-0567
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-01-18 17:37:57 | Re: Abnormally high memory usage/OOM triggered |
| Previous Message | Davlet Panech | 2018-01-18 17:13:33 | Re: Abnormally high memory usage/OOM triggered |