Re: Bad planning data resulting in OOM killing of postgres

Thanks Jeff,

No triggers or foreign key constrains:

psql:postgres(at)cipafilter = \d+ titles
Table "public.titles"
Column │ Type │ Modifiers
│ Storage │ Stats target │ Description
─────────┼───────────────────┼──────────────────────────────────────────────────────────┼──────────┼──────────────┼─────────────
title │ character varying │
│ extended │ │
titleid │ integer │ not null default
nextval('titles_titleid_seq'::regclass) │ plain │ │
Indexes:
"titles_pkey" PRIMARY KEY, btree (titleid)
"titles_md5_title_idx" btree (md5(title::text))

Do you see anything in there that would be problematic?

On Mon, Feb 13, 2017 at 2:41 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> On Mon, Feb 13, 2017 at 11:53 AM, David Hinkle <hinkle(at)cipafilter(dot)com>
> wrote:
>>
>> Thanks guys, here's the information you requested:
>>
>> psql:postgres(at)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

--
David Hinkle

Senior Software Developer

Phone: 800.243.3729x3000

Email: hinkle(at)cipafilter(dot)com

Hours: Mon-Fri 8:00AM-5:00PM (CT)