Re: Postgres 17.4 is much slower than Postgres 15.12 using RECURSIVE
От | David Rowley |
---|---|
Тема | Re: Postgres 17.4 is much slower than Postgres 15.12 using RECURSIVE |
Дата | |
Msg-id | CAApHDvq0SbTK1tC0gN53xpTZTqjbGyZyV0P87wb3qFE-jFg3nA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Postgres 17.4 is much slower than Postgres 15.12 using RECURSIVE (marcos sicat <marcos.sicat@atlasifs.com>) |
Ответы |
Re: Postgres 17.4 is much slower than Postgres 15.12 using RECURSIVE
|
Список | pgsql-bugs |
On Thu, 1 May 2025 at 09:43, marcos sicat <marcos.sicat@atlasifs.com> wrote: > I was able to capture the Qplans for both, and I highlighted the differences in red. Are there server settings differencesbetween v17 and v15 by default? > > What would be the suggested configuration settings in v17 that would behave like v15 and match the performance with v15? (I'd recommend in the future attaching two text files, one for each plan. You might find people don't want to open spreadsheets received through email.) It looks like v17 doesn't want to use the indexgraph1D index on prod_itchbbo_p_small_message. You should check if that index exists on the v17 instance. v17 does see the Seq Scan as the cheaper option. I'm unsure why that would have changed between v15 and v17. Are seq_page_cost, random_page_cost, and effective_cache_size all set to the same as on v15? You could do: create index on prod_itchbbo_p_small_message (order_book, date(added_date)); and the planner would likely make use of the more selective index. The "printable" might be worth adding as well, depending on how many rows you still see in the "Rows Removed by Filter". David
В списке pgsql-bugs по дате отправления: