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  (David Hinkle <hinkle@cipafilter.com>)
Список 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 по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: [GENERAL] Postgres
Следующее
От: David Hinkle
Дата:
Сообщение: Re: [GENERAL] Bad planning data resulting in OOM killing of postgres