Re: Queries containing ORDER BY and LIMIT started to work slowly

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Rondat Flyag <rondatflyag(at)yandex(dot)ru>
Cc: "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org>
Subject: Re: Queries containing ORDER BY and LIMIT started to work slowly
Date: 2023-08-29 20:11:39
Message-ID: CAMkU=1yX2TtLw+Fcb=ZSYWmGvY-Mx1LOAU67VTryZLMcor6gRA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Aug 29, 2023 at 2:55 PM Rondat Flyag <rondatflyag(at)yandex(dot)ru> wrote:

> I took the dump just to store it on another storage (external HDD). I
> didn't do anything with it.
>

I don't see how that could cause the problem, it is probably just a
coincidence. Maybe taking the dump held a long-lived snapshot open which
caused some bloat. But if that was enough to push your system over the
edge, it was probably too close to the edge to start with.

Do you have a plan for the query while it was fast? If not, maybe you can
force it back to the old plan by setting enable_seqscan=off or perhaps
enable_sort=off, to let you capture the old plan for comparison.

The estimate for the seq scan of isbns_statistics is off by almost a
factor of 2. A seq scan with no filters and which can not stop early
should not be hard to estimate accurately, so this suggests autovac is not
keeping up. VACUUM ANALYZE all of the involved tables and see if that
fixes things.

Cheers,

Jeff

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Rick Otten 2023-08-29 21:06:54 Re: Queries containing ORDER BY and LIMIT started to work slowly
Previous Message Jeff Janes 2023-08-29 19:43:05 Re: Index bloat and REINDEX/VACUUM optimization for partial index