Re: [GENERAL] Bad planning data resulting in OOM killing of postgres - Mailing list pgsql-general

From Jeff Janes
Subject Re: [GENERAL] Bad planning data resulting in OOM killing of postgres
Date
Msg-id CAMkU=1yNoi6voHfHxWdg57+4CvAthyfzL2XaqJM9+CSF4a3_Wg@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Bad planning data resulting in OOM killing of postgres  (David Hinkle <hinkle@cipafilter.com>)
Responses Re: [GENERAL] Bad planning data resulting in OOM killing of postgres  (David Hinkle <hinkle@cipafilter.com>)
List pgsql-general
On Mon, Feb 13, 2017 at 12:43 PM, David Hinkle <hinkle@cipafilter.com> wrote:
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?


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

pgsql-general by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: [GENERAL] Postgres
Next
From: David Hinkle
Date:
Subject: Re: [GENERAL] Bad planning data resulting in OOM killing of postgres