Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eEyUX-0008CE-BU for pgsql-performance@arkaria.postgresql.org; Wed, 15 Nov 2017 14:16:37 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1eEyUW-0003gj-3t for pgsql-performance@arkaria.postgresql.org; Wed, 15 Nov 2017 14:16:36 +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 1eEyUV-0003ga-Id for pgsql-performance@postgresql.org; Wed, 15 Nov 2017 14:16:35 +0000 Received: from mail-io0-x230.google.com ([2607:f8b0:4001:c06::230]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eEyUN-0006k7-3x for pgsql-performance@postgresql.org; Wed, 15 Nov 2017 14:16:35 +0000 Received: by mail-io0-x230.google.com with SMTP id z74so1686040iof.12 for ; Wed, 15 Nov 2017 06:16:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :in-reply-to:user-agent; bh=0+9Uv2+E2HfCB/9+cqEg6524Lh/6TphBCLGp8kkDxRg=; b=psFMQBBL8yYJBI5JK8lDiJG10KQX3YLLlUsZuyVKzgnVTtioasuEpU3AG60yZ+wFUG C+ee5IsY4SP5bCxXVpZ+7UFyGFKeCuqGkT/EBhEpQ84HAKtM7xJiXXIKVs0D7wkXVZeW AC7/JDYO/oYssEEVUmOYL78XYUgdgl1j86C+uWrW99gIiuD/46I08MuKLCnCNH/rrT1O ofgUbprH0GX/hD02lbx2oiCd9hicrxswXk41ohuaDSbSb4fd36Kx8UWuK4lpnN0PODxD 9IQzClyN2CwZKfJf82/pBjvHsEjFNf14hPkxXyK4eNNIkBfRMuoPvOp4A30UCNJv937h F9Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:in-reply-to:user-agent; bh=0+9Uv2+E2HfCB/9+cqEg6524Lh/6TphBCLGp8kkDxRg=; b=rC9HhIxA2+/MDTPsU8afGwcTfdRkInW0dbjwQY40VoKdmXfZOfpZLdbROQtyf+s0cY ydYdlz7mfmwIZD4h6K3t1qtLUk8wqF6ONwJMLYHJ4VPZIGpwk+MGymvegCWAlkvQFYkW kcCqSpSpuPWCvWGp+rk1Yc4cIWQOze2LCQs6Yulo531Z6sM2OfPjMB6MYPRKy9bOtjgu jHmLHztrOO+1gj39wBt2POGSUFW/idSqyv/RkZw5jBnyMxy2KHAxclLcyVSnKJfHgMxC l0SRRVfQXyX//ARGA+5IizL7Ta/zncpFn19V279scHo3SCcnGNqKr6YrT0wU/DagIdVB 4Psg== X-Gm-Message-State: AJaThX6DOjHiHzAXhP6Agpo3G165UQvH/yDZU6nMVn27KwlMQJYlwtg3 M8hpLpFPfZs4JUPpLlieUnv2MQ== X-Google-Smtp-Source: AGs4zMY/esJ25Yw3FhhcbjcsCaCwJC8ZJeQhBUmSd7joUObO6V+Rfau0aQXTFXdyRNGKKjdWPFexhA== X-Received: by 10.107.146.86 with SMTP id u83mr18986547iod.37.1510755383213; Wed, 15 Nov 2017 06:16:23 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id r17sm1611487ioe.88.2017.11.15.06.16.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 06:16:22 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id 87EA480102F; Wed, 15 Nov 2017 08:16:21 -0600 (CST) Date: Wed, 15 Nov 2017 08:16:21 -0600 From: Justin Pryzby To: Samir Magar Cc: pgsql-performance@postgresql.org, Pavel Stehule Subject: Re: query performance issue Message-ID: <20171115141621.GV2167@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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 On Wed, Nov 15, 2017 at 03:03:39PM +0530, Samir Magar wrote: > I am having performance issues with one of the query. > The query is taking 39 min to fetch 3.5 mil records. > > I want to reduce that time to 15 mins. > could you please suggest something to its performance? > "HashAggregate (cost=4459.68..4459.69 rows=1 width=27) (actual time=2890035.403..2892173.601 rows=3489861 loops=1)" Looks to me like the problem is here: > " -> Index Only Scan using idxdq7 on dlr_qlfy (cost=0.43..4.45 ROWS=1 width=16) (actual time=0.009..0.066 ROWS=121 loops=103987)" > " Index Cond: ((qlfy_grp_id = dlr_grp.dlr_grp_id) AND (qlf_flg = 'N'::bpchar) AND (cog_grp_id = dlr_grp_dlr_xref_1.dlr_grp_id))" > " Heap Fetches: 0" Returning 100x more rows than expected and bubbling up through a cascade of nested loops. Are those 3 conditions independent ? Or, perhaps, are rows for which "qlfy_grp_id=dlr_grp.dlr_grp_id" is true always going to have "cog_grp_id = dlr_grp_dlr_xref_1.dlr_grp_id" ? Even if it's not "always" true, if rows which pass the one condition are more likely to pass the other condition, this will cause an underestimate, as obvserved. You can do an experiment SELECTing just from those two tables joined and see if you can reproduce the problem with poor rowcount estimate (hopefully in much less than 15min). If you can't drop one of the two conditions, you can make PG treat it as a single condition for purpose of determining expected selectivity, using a ROW() comparison like: ROW(qlfy_grp_id, cog_grp_id) = ROW(dlr_grp.dlr_grp_id, dlr_grp_dlr_xref_1.dlr_grp_id) If you're running PG96+ you may also be able to work around this by adding FKs. Justin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance