Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lBPUs-0005Q7-5o for pgsql-performance@arkaria.postgresql.org; Sun, 14 Feb 2021 22:04:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lBPUp-0006tV-FZ for pgsql-performance@arkaria.postgresql.org; Sun, 14 Feb 2021 22:04:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lBPUp-0006qu-3W for pgsql-performance@lists.postgresql.org; Sun, 14 Feb 2021 22:04:03 +0000 Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lBPUk-00078n-6Y for pgsql-performance@lists.postgresql.org; Sun, 14 Feb 2021 22:04:01 +0000 Received: by mail-ej1-x62f.google.com with SMTP id lg21so8299486ejb.3 for ; Sun, 14 Feb 2021 14:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rNAR2oKmlulG4CoNosLZssskAxScydyQO0LlQsRhpiE=; b=R1wbs5ZsrhMAnUv1L7yfbem4Z1X4SEXLA/D3X6K4QIsgDHekYetSjGfcSxDlPQKudy 5fTPq5Uo0VTAMfN3gcVOH/DqUXadmd+aHOiKS9gXh6g2T4I8saNDz/gfVKfXDgBSoPQB aFDPFKOV/bkwrKvOsf8armhIqw4cmtR4VgEYpGjmGuvcr+C0qlrOqH+SRkI3tRWWF1TD /5b9uYq36Xbuyj58003kmNZeXhW6dkhrkWCmN4n0uBqCMe6a2ZDsYnK5p7h84DFl54Ot HOArRN7ka4EHCLH4u0KDeMTktF2J2vNlwzy/9cqcwMXjlxcuN0bHTmcgpPZqqy8jPYp0 OkqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rNAR2oKmlulG4CoNosLZssskAxScydyQO0LlQsRhpiE=; b=BVciIWaDivNWHo24gf8XhKA3bj6qoYIQVnIsQInxPaTZ2NVnGvx4OEUAoLoYJ10scx SZqjrwwBVrpMfoH4b8+8PD5w6OQupF/3LcpKoWbu1T3tr5Kr09Ys4Gn4CQySoOHK7qoY lbzEVdmZtwOt1zuHUMI4pdtM2s2/F6wgmG8Vd+k+YGFgAv53dix3lsPnwa+8z0ds+puS O7XttGDf2Q0LUcdRolQ+v2oSXABIX+ZHKWrdfcQJXybaUjpjuHSW+LRr5DbIfqMSw0CH 6bE9FkrR6UR4FVNUNZn2XMprf8riFFaf0SkqKo3b5XnOSzcfavYMWs3+2u7vlKoc4cox ZqDw== X-Gm-Message-State: AOAM531Wv99wE3+WC5kpPuNFAFnn/UZ0IRMGnow8M7LdlzhmmwqloJEM qQzUPZ6SFOI11vL0voFTAmXmyfQ+QXnLdXjPgNHLB/z9QpiJSLLyWJS2ksFvs9OvNE/tnw2Ca+F WVqD7VOodzKo5tlrYlaxgybT4IQDmjT/C2ncneJ4UMF9GRCzNqh9DVcDSjGTuGX8+Pc98MR39NC i5QDy59byjRn2ZBod+E1YJUOm5mYV+AohzZak2pGgh0ZiUCdgGcmSwlpV3sUC9op/EZusQS2rtp PTD5DT8YZRrt3frIR+LBhjOsKWu9mVl0rK2aMJJajjktjaYCTKQB+BxwMmsC97F X-Google-Smtp-Source: ABdhPJwuAgMWtqGAv5EqkpfTkkWLbOBM/tROvhYn5BwPeBJ3Z5qAgN69dPchSyguu1v76zr4TqGV+g== X-Received: by 2002:a17:906:5292:: with SMTP id c18mr10128758ejm.450.1613340234977; Sun, 14 Feb 2021 14:03:54 -0800 (PST) Received: from [10.137.0.20] (ip-86-49-253-127.net.upcbroadband.cz. [86.49.253.127]) by smtp.gmail.com with ESMTPSA id n5sm9143644edw.7.2021.02.14.14.03.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Feb 2021 14:03:54 -0800 (PST) Subject: Re: Query performance issue To: Justin Pryzby , Nagaraj Raj Cc: pgsql-performance@lists.postgresql.org References: <135856010.59446.1611280406074.ref@mail.yahoo.com> <135856010.59446.1611280406074@mail.yahoo.com> <20210122023514.GD27167@telsasoft.com> From: Tomas Vondra Message-ID: <9eff2cdd-bf22-562a-805e-95b30eda84d4@enterprisedb.com> Date: Sun, 14 Feb 2021 23:03:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210122023514.GD27167@telsasoft.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CLOUD-SEC-AV-Info: enterprisedb,google_mail,monitor X-CLOUD-SEC-AV-Sent: true X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 1/22/21 3:35 AM, Justin Pryzby wrote: > On Fri, Jan 22, 2021 at 01:53:26AM +0000, Nagaraj Raj wrote: >> Tables ddl are attached in dbfiddle -- Postgres 11 | db<>fiddle >> Postgres 11 | db<>fiddle >> Server configuration is: Version: 10.11RAM - 320GBvCPU - 32 "maintenance_work_mem" 256MB"work_mem"             1GB"shared_buffers" 64GB > >> Aggregate (cost=31.54..31.55 rows=1 width=8) (actual time=0.010..0.012 rows=1 loops=1) >> -> Nested Loop (cost=0.00..31.54 rows=1 width=8) (actual time=0.007..0.008 rows=0 loops=1) >> Join Filter: (a.household_entity_proxy_id = c.household_entity_proxy_id) >> -> Nested Loop (cost=0.00..21.36 rows=1 width=16) (actual time=0.006..0.007 rows=0 loops=1) >> Join Filter: (a.individual_entity_proxy_id = b.individual_entity_proxy_id) >> -> Seq Scan on prospect a (cost=0.00..10.82 rows=1 width=16) (actual time=0.006..0.006 rows=0 loops=1) >> Filter: (((last_contacted_anychannel_dttm IS NULL) OR (last_contacted_anychannel_dttm < '2020-11-23 00:00:00'::timestamp without time zone)) AND (shared_paddr_with_customer_ind = 'N'::bpchar) AND (profane_wrd_ind = 'N'::bpchar) AND (tmo_ofnsv_name_ind = 'N'::bpchar) AND (has_individual_address = 'Y'::bpchar) AND (has_last_name = 'Y'::bpchar) AND (has_first_name = 'Y'::bpchar)) >> -> Seq Scan on individual_demographic b (cost=0.00..10.53 rows=1 width=8) (never executed) >> Filter: ((tax_bnkrpt_dcsd_ind = 'N'::bpchar) AND (govt_prison_ind = 'N'::bpchar) AND ((cstmr_prspct_ind)::text = 'Prospect'::text)) >> -> Seq Scan on household_demographic c (cost=0.00..10.14 rows=3 width=8) (never executed) >> Filter: (((hspnc_lang_prfrnc_cval)::text = ANY ('{B,E,X}'::text[])) OR (hspnc_lang_prfrnc_cval IS NULL)) >> Planning Time: 1.384 ms >> Execution Time: 0.206 ms >> 13 rows > > It's doing nested loops with estimated rowcount=1, which indicates a bad > underestimate, and suggests that the conditions are redundant or correlated. > No, it's not. The dbfiddle does that because it's using empty tables, but the plan shared by Nagaraj does not contain any nested loops. Nagaraj, if the EXPLAIN ANALYZE does not complete, there are two things you can do to determine which part of the plan is causing trouble. Firstly, you can profile the backend using perf or some other profiles, and if we're lucky the function will give us some hints about which node type is using the CPU. Secondly, you can "cut" the query into smaller parts, to run only parts of the plan - essentially start from inner-most join, and incrementally add more and more tables until it gets too long. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company