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 по дате отправления:

Предыдущее
От: Ashutosh Sharma
Дата:
Сообщение: Re: How about using dirty snapshots to locate dependent objects?
Следующее
От: Ashutosh Sharma
Дата:
Сообщение: Re: How about using dirty snapshots to locate dependent objects?