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=1yNoi6voHfHxWdg57+4CvAthyfzL2XaqJM9+CSF4a3_Wg@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 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 по дате отправления: