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 1nXhPj-0001Xp-Sq for pgsql-performance@arkaria.postgresql.org; Fri, 25 Mar 2022 10:43:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nXhPi-0001PO-Oj for pgsql-performance@arkaria.postgresql.org; Fri, 25 Mar 2022 10:43:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nXhPi-0001PF-BH for pgsql-performance@lists.postgresql.org; Fri, 25 Mar 2022 10:43:26 +0000 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nXhPf-0001Ml-EU for pgsql-performance@postgresql.org; Fri, 25 Mar 2022 10:43:26 +0000 Received: by mail-ed1-x535.google.com with SMTP id g20so8740155edw.6 for ; Fri, 25 Mar 2022 03:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=wVN7aGbAjKJBaMLF8Qa8MTK90xuUGLiGcOgih+3SV2Y=; b=I68/8HqbCnScrCEFjL69TdJklNZAqZHvNwSSmYm5s0SkxK4zL9NFN+DaQ9p+RTw5xF Qm4FZu/pTgqXPxnfXgTLRLPgkJw1j26Pal/sqF0pKvRpONBver3gT+N1XyQPIRJnn8PB eFamvUB5YI7PmF6ObpcEF2Awlpunk0FMUI3RjnEPCwy9E4pAR+CMxAPNtTchqqZO1j9U a0X5ZRmNCKPRENeznaMV/uWOrw0jXlMlPeCk8bGg1+lBAZXiqo5G8huMuEksRBWBc6Xt PDval3WSnOgNhLiE3TnnN2NQLlvryzQrpOazMZNTycIYjWs7nBpyFtHrI70l2uWnVc0E g3ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=wVN7aGbAjKJBaMLF8Qa8MTK90xuUGLiGcOgih+3SV2Y=; b=0HVtNlcr7JrWfsmhGC86BN4pJ9wSFnxnNI7wQofMcEOjWOcA/S8IhYyIe3Nm4QbxrV 1qUWvP+ZmFxw7AGz7ej11gf/xbD9epgSEdh/fHbNypnYpi+A+eFMKTrgTIwi6+duqZ2b gyKmbOY+McpDsxfRv9VZYHiNJrVvrRffkcr8qUkggyNiQ9+P4Ybh+L6HggN55krufGQB Bm3nxB/QiDp3Ngu9E+OKbW6dIzyEg7XtDB/5FtMBb2aWRfvV860xsfiDj1HTZ6hhMZV7 mBbr5GMtpeRoHLgozPo98CA3b7zzErgQXPyhDUF/gfEnfJw5VKeYifo1sn6+OyFl8qhU H6Cw== X-Gm-Message-State: AOAM531cX2oh9/MkIM1AhnQOk2U+Cv02yG1iw3zdrYiBE7zQaC7kmPcG Y9OvJ18o1kfpYBciiHrfm/8nMg== X-Google-Smtp-Source: ABdhPJwhMIdNKZ8kiCBb/astI103HDEyBqstWU8wjaOMuBEOqbh7phr064hHgqvWPv8YvMQj9BPiow== X-Received: by 2002:a05:6402:2816:b0:419:2a8e:6d3e with SMTP id h22-20020a056402281600b004192a8e6d3emr12193000ede.47.1648205002045; Fri, 25 Mar 2022 03:43:22 -0700 (PDT) Received: from localhost.localdomain (178-190-177-238.adsl.highway.telekom.at. [178.190.177.238]) by smtp.gmail.com with ESMTPSA id b3-20020aa7d483000000b00419209d4c85sm2630677edr.66.2022.03.25.03.43.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Mar 2022 03:43:21 -0700 (PDT) Message-ID: <3de146f0ea4ae3bab84be8e1c888d64d11ca6606.camel@cybertec.at> Subject: Re: View taking time to show records From: Laurenz Albe To: "Kumar, Mukesh" , "pgsql-performance@postgresql.org" Date: Fri, 25 Mar 2022 11:43:20 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-3.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, 2022-03-24 at 15:59 +0000, Kumar, Mukesh wrote: > We have recently migrated from Oracle to PostgreSQL on version 11.4 on azure postgres PaaS instance. >   > There is 1 query which is taking approx. 10 secs in Oracle and when we ran the same query it is taking approx. 1 min >   > Can anyone suggest to improve the query as from application end 1 min time is not accepted by client. >   > Please find the query and explain analyze report from below link >   > https://explain.depesz.com/s/RLJn#stats I would split the query in two parts: the one from line 3 to line 49 of your execution plan, and the rest. The problem is the bad estimate of that first part, so execute only that, write the result to a temporary table and ANALYZE that. Then execute the rest of the query using that temporary table. Perhaps it is also enough to blindly disable nested loop joins for the whole query, rather than doing the right thing and fixing the estimates: BEGIN; SET LOCAL enable_nestloop = off; SELECT ...; COMMIT; Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com