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

From Tom Lane
Subject Re: [GENERAL] Bad planning data resulting in OOM killing of postgres
Date
Msg-id 10839.1487264080@sss.pgh.pa.us
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
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 by date:

Previous
From: Tim Bellis
Date:
Subject: Re: [GENERAL] Autovacuum stuck for hours, blocking queries
Next
From: Peter Devoy
Date:
Subject: [GENERAL] Function out there to identify pseudo-empty fields, e.g. "n/a", "--", etc?