Re: BUG #19332: Sudden 330x performance degradation of SELECT amid INSERTs
| От | David Rowley |
|---|---|
| Тема | Re: BUG #19332: Sudden 330x performance degradation of SELECT amid INSERTs |
| Дата | |
| Msg-id | CAApHDvoU4nCX3oi0SKDBt_TJ_t=ypryxp9jK5s1rf-kcEM3tcg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #19332: Sudden 330x performance degradation of SELECT amid INSERTs (Sergey Naumov <sknaumov@gmail.com>) |
| Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: