| От | Alexander Lakhin |
|---|---|
| Тема | Re: v17 vs v16 performance comparison |
| Дата | |
| Msg-id | 4e14cc4f-edaf-0820-2bdf-db8dd0a9efab@gmail.com обсуждение |
| Ответ на | Re: v17 vs v16 performance comparison (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
01.08.2024 06:41, Tom Lane wrote: > >> But beside that, I've found a separate regression. Bisecting for this degradation: >> Best pg-src-17--.* worse than pg-src-16--.* by 105.0 percents (356.63 > 173.96): s64da_tpcds.query95 >> Average pg-src-17--.* worse than pg-src-16--.* by 105.2 percents (357.79 > 174.38): s64da_tpcds.query95 >> pointed at f7816aec2. > I'm not terribly concerned about that. The nature of planner changes > like that is that some queries will get worse and some better, because > the statistics and cost estimates we're dealing with are not perfect. > It is probably worth drilling down into that test case to understand > where the planner is going wrong, with an eye to future improvements; > but I doubt it's something we need to address for v17. Please find attached two plans for that query [1]. (I repeated the benchmark for f7816aec2 and f7816aec2~1 five times and made sure that both plans are stable.) Meanwhile I've bisected another degradation: Best pg-src-17--.* worse than pg-src-16--.* by 11.3 percents (7.17 > 6.44): job.query6f and came to the commit b7b0f3f27 again. [1] https://github.com/swarm64/s64da-benchmark-toolkit/blob/master/benchmarks/tpcds/queries/queries_10/95.sql Best regards, Alexander
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера