Re: BUG #17330: EXPLAIN hangs and very long query plans

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Strahinja Kustudić <strahinjak(at)nordeus(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #17330: EXPLAIN hangs and very long query plans
Date: 2021-12-10 16:39:22
Message-ID: 70745.1639154362@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

=?UTF-8?Q?Strahinja_Kustudi=C4=87?= <strahinjak(at)nordeus(dot)com> writes:
> On Fri, Dec 10, 2021 at 10:53 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>> pá 10. 12. 2021 v 10:25 odesílatel Strahinja Kustudić <
>> strahinjak(at)nordeus(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2021-12-10 16:41:18 BUG #17333: pgdg postgresql-common pg_upgradecluster duplicate data_directory in configuration file
Previous Message Pavel Stehule 2021-12-10 16:33:55 Re: BUG #17330: EXPLAIN hangs and very long query plans