On Wed, Nov 02, 2016 at 04:05:46PM -0400, Tom Lane wrote:
> Justin Pryzby <pryzby@telsasoft.com> writes:
> > I believe the join is being (badly) underestimated, leading to a crappy plan
> > involving multiple nested loop joins, which takes 2.5 hours instead of a
> > handful of seconds; I believe that might be resolved by populating its MCV
> > list..
>
> With only two rows in the table, I'm not real sure why you'd need an MCV
> list. Could we see the actual problem query (and the other table
> schemas), rather than diving into the code first?
Sigh, yes, but understand that it's a legacy report which happens to currently
be near the top of my list of things to improve:
https://explain.depesz.com/s/5rN6
The relevant table is involved three times:
Seq Scan on two_november mike_oscar (cost=0.000..1.020 rows=2 width=18) (actual time=0.010..0.010 rows=2 loops=1)
Seq Scan on echo_oscar foxtrot (cost=0.000..209.860 rows=6,286 width=13) (actual time=0.014..2.271 rows=5,842 loops=1)
Seq Scan on two_november xray_yankee_alpha (cost=0.000..1.020 rows=2 width=18) (actual time=0.017..0.019 rows=2
loops=1)
Justin