Date: Wed, 2 Nov 2016 15:19:55 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: no MCV list of tiny table with unique columns
Message-ID: <20161102201955.GB2139@telsasoft.com>
References: <20161102185318.GA3987@telsasoft.com>
 <26162.1478117146@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <26162.1478117146@sss.pgh.pa.us>
User-Agent: Mutt/1.5.23 (2014-03-12)
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

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


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance