On Mon, 24 Nov 2025 at 00:39, Sergey Naumov <sknaumov@gmail.com> wrote:
> But I think that the bug is still relevant - 330x performance degradation due to maintenance background task that
takesminutes (it looks like inserts/selects affect autovacuum performance too and it takes a lot of time to complete)
innot that user expects from DB.
The planner not picking the most optimal plan all of the time doesn't
constitute a bug. We provide many ways, including extended statistics,
n_distinct estimate overrides, increasing stats targets and various
GUC to allow users to influence the planner when it doesn't choose the
best plan.
For your case, it sounds like autovacuum might be running an ANALYZE
and causing the planner to change plans, of which the newly chosen
plan appears to execute more slowly than the previous plan. To fix
this, something from the above list may just need to be addressed. I
suggest you look at the EXPLAIN ANALYZE output for the slow query from
before and after the slowdown. If you need help with figuring out why
the planner picked a bad plan and ways to resolve that, then the
performance mailing list might be a better place. If you happen to
have discovered any sort of bug, then it can be reported here.
David
