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 1nP4b0-00089a-00 for pgsql-performance@arkaria.postgresql.org; Tue, 01 Mar 2022 15:39:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nP4ay-0003Vb-Tl for pgsql-performance@arkaria.postgresql.org; Tue, 01 Mar 2022 15:39:24 +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 1nP4ay-0003VS-7n for pgsql-performance@lists.postgresql.org; Tue, 01 Mar 2022 15:39:24 +0000 Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nP4at-0000Rb-4Y for pgsql-performance@postgresql.org; Tue, 01 Mar 2022 15:39:23 +0000 Received: by mail-wm1-x329.google.com with SMTP id q7-20020a7bce87000000b00382255f4ca9so970302wmj.2 for ; Tue, 01 Mar 2022 07:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=0kO2a3ttYrz/lpIzwBMKjYsxdUH81VFI0MAjeKVrm1c=; b=ZtBkaOaKc9xo32KRspqtMtsjxNBF8TByG/D2IOwS7KUBhW1MKOYUl+8NEAQUTYHPQJ du0AceWTzHkZoP8aj9t5HDJqOqpEbnwsO0NFNyEkFkt6FtYTyWwfE7RsdWs172y8LXrM jojp/S1GAqRfdEGM1wOEWOYHhpZ7vmIgZqUsEFooDoXkyUXuh5kAQrlSFOGdDiH3/GQp T+TVbr3P4wcGAKqaIg0GPSh6NIc/Pn6ZcL7jalzsEpfXkT+KoKyU79iEisN1z5qp5Nnw 6pjtaT6Y+ahe7dyJPHJ1Obay5ujn2HhALrmaI/dNZhQd1LlOnt59m3rjHKzo0yNzrABS yl/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=0kO2a3ttYrz/lpIzwBMKjYsxdUH81VFI0MAjeKVrm1c=; b=hTwWRZKPbakcJAHQgm5ASSlSiQXrAPV+rYZCeN46usCvn0aAnpms4FMzLztP27sOMq 1GmQEfiaFVXtbS84pxDCNwD2HiB0QKVCK1ekXo2A94MdfdSJ5iz4GB/dBSH1aXbKmgTe IBKupvhzAkab9l/1/CuTpOLmIwu/0Vdqkpf6F7gQQO492++l7qjj1OGB46mYbsfd+OiJ ROhDVXwxB5PeNIytPSHEe0q7quZbbQLFF3B/2lGJ3WSSkvB1UMFe7ktRQJwwH7VDh89x 63FyK1bNE5ObDQlpBnUAIw1oimsx/Z74dTl5Tr8Bv7ILWFmaocF8Lj63DXnaRZowlB9L Se6w== X-Gm-Message-State: AOAM533ayQy04QicynQt7qDds4p0zT2N1O1iPT7bFWWJo7TMCwyklgbl Qu5N4zS86VxDqWvRvciiD6WSOQvyWO58UyWs2j0FCGtxWLOE0od3dGTdh4RLUo+qhtAfll60jya PDtnmwi2yZXit2sGg3LYz1zarOgWX2trGJWxY2rxDuBfe3+DQ7a0ljAFsGMVFNbtFVY9Vnki2Zs +ao7vp1N4IyNw5rtjylSXGmlqEBAxhkhHGHbzgjBGbjlWf5MU= X-Google-Smtp-Source: ABdhPJyFw+ygj2Z36KwZBEXs8LIbtqbBH6Jty+pcVkYOXDNGfahF356rDFF4Fnj3gCIwZjBwUbr+Xw== X-Received: by 2002:a05:600c:1e27:b0:381:421f:1e81 with SMTP id ay39-20020a05600c1e2700b00381421f1e81mr14073685wmb.175.1646149157691; Tue, 01 Mar 2022 07:39:17 -0800 (PST) Received: from [10.137.0.18] (static-84-42-175-93.net.upcbroadband.cz. [84.42.175.93]) by smtp.gmail.com with ESMTPSA id w6-20020a05600018c600b001efe4a49566sm5576508wrq.78.2022.03.01.07.39.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Mar 2022 07:39:17 -0800 (PST) Message-ID: <7ea8e99b-7551-94a0-fb91-91f75e062c44@enterprisedb.com> Date: Tue, 1 Mar 2022 16:39:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Never Ending query in PostgreSQL Content-Language: en-US To: "Kumar, Mukesh" , Jeff Janes Cc: "pgsql-performance@postgresql.org" References: <01028050-efd3-06af-6ffd-57722acb9051@enterprisedb.com> From: Tomas Vondra In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Archived-At: Precedence: bulk On 3/1/22 16:01, Kumar, Mukesh wrote: > Hi Tomas , > > Thanks for replying , We have identified a Join condition which is > creating a problem for that query. > > Accept my apologies for pasting the plan twice. I am attaching the > query again in this mail > Queries without explain (or even better "explain analyze") are useless. We don't have the data, we don't know what the executed plan is, we don't know what plan might be a better one. There's a wiki page about reporting slow queries (what info to include, etc): https://wiki.postgresql.org/wiki/Slow_Query_Questions > We have found that by evicting the View paymenttransdetails_view from > the attached query runs in approx. 10 secs and the view contains > multiple conditions and 1 jojn as well. > You need to add individual tables, not a view which is itself a join of 10+ tables. The idea is that you start with a fast query, add tables one by one (in the join order from the explain). You'll be able to do EXPLAIN ANALYZE and watch estimate accuracy, and then at some point it gets much slower, which is the join that causes trouble. But you might still be able to do explain analyze. So looking at the explain plan you shared before, you'd start with a join of so_vendor_address_base + so_vendor_base, and then you'd add - sapecc_lfa1_assoc - lms_payment_item_vendor_base - lms_payment_line_item_base - lms_payment_check_request - lms_pay_line_item_acct_base - ... (in this order). I'd bet "lms_payment_check_request" is where things start to go south. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company