Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cTahx-0000Nq-9n for pgsql-general@arkaria.postgresql.org; Tue, 17 Jan 2017 20:50:21 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cTahw-0004Mf-LC for pgsql-general@arkaria.postgresql.org; Tue, 17 Jan 2017 20:50:20 +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 1cTafd-0001NK-MV for pgsql-general@postgresql.org; Tue, 17 Jan 2017 20:47:57 +0000 Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cTafZ-0003jF-U5 for pgsql-general@postgresql.org; Tue, 17 Jan 2017 20:47:56 +0000 Received: by mail-wm0-x22d.google.com with SMTP id c206so242509158wme.0 for ; Tue, 17 Jan 2017 12:47:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=gyCV6of9K0lEaINZi/aVDkYpRoh9Egw3wFsLpQhjU5c=; b=iRPq6UKBfiBwFI6XpvRXZ5GGZ18B/0N8vOwd9L1tjQEu3u6g7/HLR4+Cnxi3Q76A18 6J+SNTzHrHgz7SwmSlTtNYKtIEm6GRRhmwq48yskTR3+YKqG0uc2gGoiK0qY/ncRpBZq 1hWYfH+yf0yV0i1FlyiTJlD8bLQX5PEHUrp88xkuXFScm3jnSBvVsF52IUtggG6OLgCi rJAFit3iBLC/cHTgb6QP2Pt7iwQWjKnJC+PDERnvh006+CaMIrRW2+wHh9K/CfCjB4MI rBigeQ45U3VbH49xCMlIp25kTHzBgVsNVz/MwtZrvrzgrKrsIImZbNkBQAWoy5c5tck3 c2gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=gyCV6of9K0lEaINZi/aVDkYpRoh9Egw3wFsLpQhjU5c=; b=KV4b0MQAcFjYxKnrxLyDHRAjvyiCvOTiXffRk8FsPPHY0coKLCLk7RyE/AsnNfOUHz 9jm6ICNJhySTNfr9t7RjAuFQmxILH+TCyfrFpnAs0v7gI/szgn7AhRiTrKAkCDhq2z/Q APcdGi5KXvWQkbjx8zn5UM26OIId1YVLAcKGKIwO79PpA8jWAZFjqo9cQrsEfCl6KjqO 0ZIjcKni7bUV74oExW8+5M2Ijyw8b44NPXHwu9waFRLaZFJDVNHCcXuInp4zyuPZ+ZCr DqPobdOHmmRCICg94TYQwL51RPWIuSJ57birdE5R9u4/6w+8AmQOT9us0ex6XgRw/7m4 inUA== X-Gm-Message-State: AIkVDXJWpM/lFwmecUph4/paFP7++nDaGoOHahWC9Yv4TLC4S+oPPbmI5ExXBg4FIpS1orOK5ISu3aYZudMwEXv94NfeGbhsbhJvgbUJUxDHoSJTT4PTsh9EzmTActRoLOcCOW9RhqQ3LfXTHjAwbkjVtKD/YYX99aTUCh6HGZz5m1NUzl6Hlz4GzyBxlyPk2y2n6wCuk7CQ X-Received: by 10.223.163.201 with SMTP id m9mr8109012wrb.66.1484686072808; Tue, 17 Jan 2017 12:47:52 -0800 (PST) Received: from [10.137.2.17] (ip-89-177-46-65.net.upcbroadband.cz. [89.177.46.65]) by smtp.gmail.com with ESMTPSA id o143sm8365066wmd.3.2017.01.17.12.47.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 12:47:52 -0800 (PST) Subject: Re: Queries are taking way longer in 9.6 than 9.5 To: pgsql-general@postgresql.org References: From: Tomas Vondra Message-ID: Date: Tue, 17 Jan 2017 21:47:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-general Precedence: bulk Sender: pgsql-general-owner@postgresql.org On 01/17/2017 08:31 PM, Ravi Tammineni wrote: > Hi, > > We have recently upgraded to 9.6 and few queries are performing very > poorly. Query execution time has increased more 4 or 5 times in 9.6. > Qeruy execution plan is also completely changed. I am not sure whether > its because of Parallel feature or any bug in 9.6. There are few similar > kind of queries and all of them are taking more time in 9.6. > > Following query is taking 70ms in 9.5 and the same query is taking 2 > minutes in 9.6. Execution plan is totally different in 9.6 and seems > like there is a major flaw while generating the execution plan. Instead > of filtering the low cardinality, its filtering from biggest table. > Somehow nested loop joins are screwed up. > > I really appreciate your help. > > explain analyze > SELECT count(*) > ... You say "explain analyze" but have only provided EXPLAIN output. We need to see the EXPLAIN ANALYZE to see how accurate the estimates are. Others already recommended doing ANALYZE to collect statistics on the upgraded database - if Heroku doesn't do that automatically, I'd recommend reporting that as a bug to them. If that does not resolve the issue, run this on both machines and send the results to the mailing list: select name, setting from pg_settings where source != 'default'; That'll tell us how was the configuration modified. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general