Re: Query run in 27s with 15.2 vs 37ms with 14.6

Поиск
Список
Период
Сортировка
От Charles
Тема Re: Query run in 27s with 15.2 vs 37ms with 14.6
Дата
Msg-id CABthHP-XJXF8L_GLnWvU6Mm09B3_gJV8fy1uAPOFhLrAOPopLg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Query run in 27s with 15.2 vs 37ms with 14.6  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Query run in 27s with 15.2 vs 37ms with 14.6  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-bugs


On Tue, Feb 21, 2023 at 9:22 AM David Rowley <dgrowleyml@gmail.com> wrote:
On Tue, 21 Feb 2023 at 14:38, Charles <peacech@gmail.com> wrote:
> Disabling mergejoin on 14.6 and disabling nestedloop on 15.2 causes both to use hashjoin where it runs for 37ms in 14.6 and 208ms in 15.2.
>
> 14.6:
>                           ->  Parallel Index Scan using idx_stock_price_date on stock_price  (cost=0.43..59671.39 rows=81248 width=13) (actual time=0.021..0.689 rows=1427 loops=3)
>                                 Index Cond: (date > $0)
>                                 Filter: (value > 0)
>                                 Rows Removed by Filter: 222

> 15.2:
>                                       ->  Parallel Seq Scan on stock_price  (cost=0.00..64038.54 rows=91275 width=13) (actual time=130.043..173.124 rows=1427 loops=3)
>                                             Filter: ((value > 0) AND (date > $0))
>                                             Rows Removed by Filter: 906975

The difference in the two above fragments likely accounts for the
majority of the remaining performance difference.  Possibly 15.2 is
using a Seq Scan because it's estimating slightly more rows from
stock_price for these two quals. For the date > $0 qual, the stats
don't really help as the planner does not know what $0 will be during
planning, so it'll just assume that the selectivity is 1/3rd of rows.
For the value > 0, there could be some variation there just between
ANALYZE runs. That might be enough to account for the difference in
estimate between 14 and 15.

You might also want to check that effective_cache_size is set to
something realistic on 15. random_page_cost is also a factor for index
scan vs seq scan. 

Thank you for the hint. I think this is it. random_page_cost was set to 1.1 in 14.6 (the data directory is located in a ssd). When upgrading to 15.2 I thought that ssd random seek time is not that close to sequential seek time, so I revert it back to 4.

The new timings are
random_page_cost = 1.1 with no extended stats = still 27 seconds
random_page_cost = 1.1 with materialized cte = 92ms
random_page_cost = 1.1 with extended stats = 33ms
random_page_cost = 1.1 with extended stats and materialized cte = 33ms


В списке pgsql-bugs по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Query run in 27s with 15.2 vs 37ms with 14.6
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: BUG #17744: Fail Assert while recoverying from pg_basebackup