Re: [GENERAL] Bad planning data resulting in OOM killing of postgres

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: [GENERAL] Bad planning data resulting in OOM killing of postgres
Дата
Msg-id CAMkU=1xS=HTh0msPkLarYD4aNfL0t+KeuE18dvR6AG8k32mE+A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] Bad planning data resulting in OOM killing of postgres  (David Hinkle <hinkle@cipafilter.com>)
Ответы Re: [GENERAL] Bad planning data resulting in OOM killing of postgres
Список pgsql-general
On Mon, Feb 13, 2017 at 11:53 AM, David Hinkle <hinkle@cipafilter.com> wrote:
Thanks guys, here's the information you requested:

psql:postgres@cipafilter = show work_mem;
 work_mem
──────────
 10MB
(1 row)


OK, new theory then.  Do you have triggers on or foreign key constraints to the table you are deleting from?  It queues up each deleted row to go back and fire the trigger or validate the constraint at the end of the statement.  You might need to drop the constraint, or delete in smaller batches by adding some kind of dummy condition to the WHERE clause which you progressively move.

Or select the rows you want to keep into a new table, and then drop the old one, rename the new one, and rebuild any constraints or indexes and other dependencies.  This can be pretty annoying if there a lot of them.

Cheers,

Jeff

В списке pgsql-general по дате отправления:

Предыдущее
От: David Hinkle
Дата:
Сообщение: Re: [GENERAL] Bad planning data resulting in OOM killing of postgres
Следующее
От: David Hinkle
Дата:
Сообщение: Re: [GENERAL] Bad planning data resulting in OOM killing of postgres