Re: Postgresql OOM - Mailing list pgsql-hackers

From Radu Radutiu
Subject Re: Postgresql OOM
Date
Msg-id CAG4TxrgMjyjc5k=cJin-+tK-7Ua0MZVGQryOQoBRcfBPUnoMkw@mail.gmail.com
Whole thread Raw
In response to Re: Postgresql OOM  (Pantelis Theodosiou <ypercube@gmail.com>)
Responses Re: Postgresql OOM
List pgsql-hackers

I am not qualified to answer on the OOM issue but why are you joining the same table (outputrequest) 4 times (using an identical join condition)?
This essentially does a cross join, if an input_sequence value has say, 1000 related rows in outputrequest, you will be getting 1000^4 rows in the result set.

The query itself runs fine in a reasonable time with enable_parallel_hash = 'off'. I see two problems - one is the wrong execution plan (right after running analyze), the second and the most important is the huge memory usage (far exceeding work_mem and shared buffers) leading to OOM. 
See https://explain.depesz.com/s/yAqS for the explain plan with enable_parallel_hash = 'off. 

pgsql-hackers by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Re: How about using dirty snapshots to locate dependent objects?
Next
From: Ashutosh Sharma
Date:
Subject: Re: How about using dirty snapshots to locate dependent objects?