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 1mviwD-0005YZ-IE for pgsql-bugs@arkaria.postgresql.org; Fri, 10 Dec 2021 16:40:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mvivh-0004OG-0G for pgsql-bugs@arkaria.postgresql.org; Fri, 10 Dec 2021 16:39:29 +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 1mvivg-0004O7-Nt for pgsql-bugs@lists.postgresql.org; Fri, 10 Dec 2021 16:39:28 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mvivd-0005sC-VZ for pgsql-bugs@lists.postgresql.org; Fri, 10 Dec 2021 16:39:28 +0000 Received: from pro.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 1BAGdM4K3942821; Fri, 10 Dec 2021 11:39:22 -0500 From: Tom Lane To: =?UTF-8?Q?Strahinja_Kustudi=C4=87?= cc: Pavel Stehule , Peter Geoghegan , PostgreSQL mailing lists Subject: Re: BUG #17330: EXPLAIN hangs and very long query plans In-reply-to: References: <17330-0d6d4cf6ff440a65@postgresql.org> Comments: In-reply-to =?UTF-8?Q?Strahinja_Kustudi=C4=87?= message dated "Fri, 10 Dec 2021 16:52:45 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <70743.1639154362.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Fri, 10 Dec 2021 11:39:22 -0500 Message-ID: <70745.1639154362@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk =?UTF-8?Q?Strahinja_Kustudi=C4=87?= writes: > On Fri, Dec 10, 2021 at 10:53 AM Pavel Stehule > wrote: >> pá 10. 12. 2021 v 10:25 odesílatel Strahinja Kustudić < >> strahinjak@nordeus.com> napsal: >>> I allowed EXPLAIN in Docker to finish and it took almost 500 seconds and >>> it was reading data all the time. After I reindexed the biggest table, >>> EXPLAIN finished instantly. Can the index corruption cause this? >> The index can be bloated. > Is bloat just enough to make it slower, or the index needs to be corrupted? bloat != corruption. The problem you're dealing with here is a whole lot of dead index entries at the very end of the index range (could be either the lowest or highest entries). The planner is wasting time scanning through those to find the extremal non-dead value for a range estimate. REINDEX got rid of the dead entries; a VACUUM would have done as well. As noted upthread, more recent PG versions are a bit smarter about such cases. regards, tom lane