Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XBZan-0003go-Mx for pgsql-performance@arkaria.postgresql.org; Mon, 28 Jul 2014 01:19:09 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XBZam-0004k9-6Y for pgsql-performance@arkaria.postgresql.org; Mon, 28 Jul 2014 01:19:08 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XBZal-0004k2-8o for pgsql-performance@postgresql.org; Mon, 28 Jul 2014 01:19:07 +0000 Received: from mail-pa0-x233.google.com ([2607:f8b0:400e:c03::233]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XBZah-0003Ol-Hp for pgsql-performance@postgresql.org; Mon, 28 Jul 2014 01:19:05 +0000 Received: by mail-pa0-f51.google.com with SMTP id ey11so9394848pad.24 for ; Sun, 27 Jul 2014 18:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:date:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lPWuqmjrA+ezXY9227b7QE1qI4G3ZuHHFQJpUJ6NS/o=; b=uRh8Ft3xglIhZe56uGZqO2ubz7ruRVwjSx0DciXr98Delb7WGFiBeK35nKHg3i4DOm 8mKAjsR8VzPzAXX2c/N081GMBGo55eciZSxP39M1kRPwdmbgOz07Ppq9Sj7TtL9ppR1Y uyp2M25gKkO+WLlHX/YUlkOpLbtspK4H8UGwjH0ru69KWK6gc5ENs7o18Xcj93vzheSN WbyYywyb0wSQz+lLPViWiwqLNO1gsmody1Yqn78uxJlcI0OVes1xMWMGX+78haHLRUoK Pg1wkHcSLopxCqnQTAA53UN3blzFTqwCpN/tOOKq1PxN7+euOk119JbAOx1BCkxq4yYI nHMA== X-Received: by 10.66.102.73 with SMTP id fm9mr35453968pab.72.1406510341806; Sun, 27 Jul 2014 18:19:01 -0700 (PDT) Received: from [192.168.2.106] ([116.226.74.154]) by mx.google.com with ESMTPSA id fb4sm60972665pac.30.2014.07.27.18.18.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Jul 2014 18:19:01 -0700 (PDT) From: Rural Hunter X-Google-Original-From: Rural Hunter Message-ID: <53D5A503.5060406@gmail.com> Date: Mon, 28 Jul 2014 09:18:59 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Tom Lane CC: "pgsql-performance@postgresql.org" Subject: Re: Very slow planning performance on partition table References: <53CFB6BC.4050606@gmail.com> <25010.1406253203@sss.pgh.pa.us> <53D26875.2080604@gmail.com> <53D51E49.102@gmail.com> <24564.1406478487@sss.pgh.pa.us> In-Reply-To: <24564.1406478487@sss.pgh.pa.us> Content-Type: text/plain; charset=gb18030; format=flowed Content-Transfer-Encoding: 8bit X-Pg-Spam-Score: -2.0 (--) 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 Yes I checked. The connection I inspected is the longest running one. There was no other connections blocking it. And I also see all locks are granted for it. Does the planning phase require some internal locks? ÔÚ 2014/7/28 0:28, Tom Lane дµÀ: > Yeah, that's what the stack trace suggests. Have you looked into pg_locks > and pg_stat_activity to see which lock it wants and what's holding said > lock? > > 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