Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c21ou-0002bU-8i for pgsql-performance@arkaria.postgresql.org; Wed, 02 Nov 2016 20:07:36 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1c21ot-0005F5-Rv for pgsql-performance@arkaria.postgresql.org; Wed, 02 Nov 2016 20:07:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c21nD-00029B-SA for pgsql-performance@postgresql.org; Wed, 02 Nov 2016 20:05:51 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c21nA-0006ml-6O for pgsql-performance@postgresql.org; Wed, 02 Nov 2016 20:05:50 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id uA2K5k4H026163; Wed, 2 Nov 2016 16:05:46 -0400 From: Tom Lane To: Justin Pryzby cc: pgsql-performance@postgresql.org Subject: Re: no MCV list of tiny table with unique columns In-reply-to: <20161102185318.GA3987@telsasoft.com> References: <20161102185318.GA3987@telsasoft.com> Comments: In-reply-to Justin Pryzby message dated "Wed, 02 Nov 2016 13:53:18 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26161.1478117146.1@sss.pgh.pa.us> Date: Wed, 02 Nov 2016 16:05:46 -0400 Message-ID: <26162.1478117146@sss.pgh.pa.us> X-Pg-Spam-Score: -4.6 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Justin Pryzby 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? regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance