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 1nXyBO-0002ZN-JK for pgsql-performance@arkaria.postgresql.org; Sat, 26 Mar 2022 04:37:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nXyBN-0004cA-B6 for pgsql-performance@arkaria.postgresql.org; Sat, 26 Mar 2022 04:37:45 +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 1nXyBN-0004c1-1E for pgsql-performance@lists.postgresql.org; Sat, 26 Mar 2022 04:37:45 +0000 Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nXyBK-0008Ka-BL for pgsql-performance@postgresql.org; Sat, 26 Mar 2022 04:37:44 +0000 Received: by mail-ej1-x62a.google.com with SMTP id qa43so18853521ejc.12 for ; Fri, 25 Mar 2022 21:37:41 -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=C3YPwYbIU7sn20i0k4m5csTOyi+LamI8dgEMKv3xn40=; b=bcpjNPP2RqP3aVDc7dKFhkBbVR5BPHMl0T997nc4rBBOtFBUJJM+28yZuZ3jXTeMrh TN1aFVhlQDUphKdH0iMiGdDPYKPE0weahK7qW1isbGH/oleqn01skKi85WEtMVkj3iGV lrBHYSDdgS0CbPDJ9XYz6HnClWb9XrpD+4Lczit+2mfospDfMcxYle0Ad4SG7jTbOeiv NfrxbTRgsiltbo5MAD28NhWrtR1JYDKZM4aMTjRDNzRlYramr1TVddaYUw2hrcFpmF1c zwd8u/Dqf2za3h0Tl7V+z5qUOpHT2z4nTTXbvXNebqhlHhmgH8PLwmre2AVmCxdKvtyF DF6w== 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=C3YPwYbIU7sn20i0k4m5csTOyi+LamI8dgEMKv3xn40=; b=60GaVm6LeJieN4N5gpW2s1aRCZ1pqVuUvzZfV8BIVhhYRQ/UVJysnCao5Oe4pCg5aY X7dXcZGabJr9Sf0t2pcc/VcoeZoq+etkEIZGNEGfQHYSTEnqTtx/lh64JQo/UglEwbRR 6ATULh+q/CeAudxKfBro8ILvxoYVs66q8xlJQq8tFB7EoRCdoaHlA3+JdTazJkkO/fBv JlwoedeJeqH6BMmk7GIDEcG65tvGcIZwFi9hVqvQnZY4EdJsjbnkImI/uuvi5v6gg0Xh yRrDR4VU9Zfl5I/gWepUii/Ne+3q/iRsdv008f+sImEEWlClX9GsOwgCaWv0BESM8rKc 60Xg== X-Gm-Message-State: AOAM5304Hck4+ZTwM+Jhljo47R/TnTt0VfUV/mEDYG+giCGZCEvooYun UGbVuXAJOWxV1fMMrgNdTZBPk5QQVM5lrw== X-Google-Smtp-Source: ABdhPJzGMr3oBUhYSbCzO/D3XbJocNxpq1sXRsvfIjdJD86kR3RYl7X9H17vlOn6JR0QlURP7j68NA== X-Received: by 2002:a17:906:c110:b0:6e0:dc2a:3393 with SMTP id do16-20020a170906c11000b006e0dc2a3393mr362131ejc.512.1648269459611; Fri, 25 Mar 2022 21:37:39 -0700 (PDT) Received: from localhost.localdomain (178-190-183-69.adsl.highway.telekom.at. [178.190.183.69]) by smtp.gmail.com with ESMTPSA id a102-20020a509eef000000b0041614c8f79asm3581819edf.88.2022.03.25.21.37.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Mar 2022 21:37:39 -0700 (PDT) Message-ID: <2988e92ed6eb90d60014d2f879c73bc9ceaf5d1f.camel@cybertec.at> Subject: Re: View taking time to show records From: Laurenz Albe To: "Kumar, Mukesh" , "pgsql-performance@postgresql.org" Date: Sat, 26 Mar 2022 05:37:38 +0100 In-Reply-To: References: <3de146f0ea4ae3bab84be8e1c888d64d11ca6606.camel@cybertec.at> 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: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, 2022-03-25 at 14:07 +0000, Kumar, Mukesh wrote: > > [recommendation to fix the estimate] > > > > 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; > > Thanks for the below suggestion , When I ran the query with the parameter , it is taking only 1 sec. > > So could you please let me know if I can put this parameter to OFF . at database and it will not > create any issues to queries running in database. That will very likely cause problems in your database, because sometimes a nested loop join is by far the most efficient way to run a query. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com