Re: Postgresql OOM
| От | Radu Radutiu |
|---|---|
| Тема | Re: Postgresql OOM |
| Дата | |
| Msg-id | CAG4TxrgMjyjc5k=cJin-+tK-7Ua0MZVGQryOQoBRcfBPUnoMkw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Postgresql OOM (Pantelis Theodosiou <ypercube@gmail.com>) |
| Ответы |
Re: Postgresql OOM
|
| Список | 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 по дате отправления: