Re: Bad planning data resulting in OOM killing of postgres

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: David Hinkle <hinkle(at)cipafilter(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Bad planning data resulting in OOM killing of postgres
Date: 2017-02-13 21:21:22
Message-ID: CAMkU=1yNoi6voHfHxWdg57+4CvAthyfzL2XaqJM9+CSF4a3_Wg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Feb 13, 2017 at 12:43 PM, David Hinkle <hinkle(at)cipafilter(dot)com>
wrote:

> 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?
>

I'm out of ideas here. What happens if you just select the rows, rather
than deleting them? Does it have memory problems then? If not, can you
post the explain (analyze, buffers) of doing that?

Cheers,

Jeff

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David Hinkle 2017-02-13 21:47:08 Re: Bad planning data resulting in OOM killing of postgres
Previous Message Merlin Moncure 2017-02-13 21:13:53 Re: Postgres