Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1V5Hd0-0000U4-QZ for pgsql-performance@arkaria.postgresql.org; Fri, 02 Aug 2013 15:50:55 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1V5Hd0-00033x-2X for pgsql-performance@arkaria.postgresql.org; Fri, 02 Aug 2013 15:50:54 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1V5Hcy-00033q-Ux for pgsql-performance@postgresql.org; Fri, 02 Aug 2013 15:50:53 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1V5Hcv-0005ED-S4 for pgsql-performance@postgresql.org; Fri, 02 Aug 2013 15:50:52 +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 r72FomWb001900; Fri, 2 Aug 2013 11:50:48 -0400 From: Tom Lane To: Jeff Janes cc: Sergey Burladyan , "pgsql-performance@postgresql.org" Subject: Re: Looks like merge join planning time is too big, 55 seconds In-reply-to: References: <8761vpwid4.fsf@seb.koffice.internal> <87li4lusvd.fsf@seb.koffice.internal> <87li4l9j34.fsf@home.progtech.ru> <87k3k5kkup.fsf@home.progtech.ru> Comments: In-reply-to Jeff Janes message dated "Fri, 02 Aug 2013 08:29:34 -0700" Date: Fri, 02 Aug 2013 11:50:48 -0400 Message-ID: <1899.1375458648@sss.pgh.pa.us> X-Pg-Spam-Score: -3.4 (---) 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 Jeff Janes writes: > On Thu, Aug 1, 2013 at 5:16 PM, Sergey Burladyan wrote: >> If I not mistaken, may be two code paths like this here: >> (1) mergejoinscansel -> scalarineqsel-> ineq_histogram_selectivity -> get_actual_variable_range -> index_getnext >> (2) scalargtsel -> scalarineqsel -> ineq_histogram_selectivity -> get_actual_variable_range -> index_getnext > Yeah, I think you are correct. mergejoinscansel does *not* call scalarineqsel, nor get_actual_variable_range. It calls get_variable_range, which only looks at the pg_statistic entries. I think we need to see the actual stack traces, not incomplete versions. It's possible that the situation here involves bloat in pg_statistic, but we're just leaping to conclusions if we assume that that's where the index fetches are occurring. 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