Re: [GENERAL] Bad planning data resulting in OOM killing of postgres

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] Bad planning data resulting in OOM killing of postgres
Дата
Msg-id 10839.1487264080@sss.pgh.pa.us
обсуждение исходный текст
Ответ на 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
David Hinkle <hinkle@cipafilter.com> writes:
> Tom, there are three columns in this table that exhibit the problem,
> here is the statistics data after an analyze, and the real data to
> compare it to.

>  attname | n_distinct |  most_common_freqs

>  titleid |        292 | {0.767167}

Ouch.  That's saying there's some single value of titleid that accounts
for more than three-quarters of the entries ... does that square with
reality?  That'd certainly explain why a hash join goes nuts.

            regards, tom lane


В списке pgsql-general по дате отправления:

Предыдущее
От: Tim Bellis
Дата:
Сообщение: Re: [GENERAL] Autovacuum stuck for hours, blocking queries
Следующее
От: Peter Devoy
Дата:
Сообщение: [GENERAL] Function out there to identify pseudo-empty fields, e.g. "n/a", "--", etc?