Thanks Jeff,
No triggers or foreign key constrains:
psql:postgres@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.janes@gmail.com> wrote:
> 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
--
David Hinkle
Senior Software Developer
Phone: 800.243.3729x3000
Email: hinkle@cipafilter.com
Hours: Mon-Fri 8:00AM-5:00PM (CT)
