Performance Evaluation of Result Cache by using TPC-DS
От | Yuya Watari |
---|---|
Тема | Performance Evaluation of Result Cache by using TPC-DS |
Дата | |
Msg-id | CAJ2pMkZDurqO2S8zEvfF6NcrBZO_HFPHEjv_=9c79ag_ejYy5g@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Performance Evaluation of Result Cache by using TPC-DS
|
Список | pgsql-hackers |
Hello, Recently, the result cache feature was committed to PostgreSQL. I tested its performance by executing TPC-DS. As a result, I found that there were some regressions in the query performance. I used the TPC-DS scale factor 100 in the evaluation. I executed all of the 99 queries in the TPC-DS, and the result cache worked in the 21 queries of them. However, some queries took too much time, so I skipped their execution. I set work_mem to 256MB, and max_parallel_workers_per_gather to 0. Evaluation results are as follows. The negative speedup ratio indicates that the execution time increased by the result cache. Query No | Execution time with result cache | Execution time without result cache | Speedup ratio 7 142.1 142.2 0.03% 8 144.0 142.8 -0.82% 13 164.6 162.0 -1.65% 27 138.9 138.7 -0.16% 34 135.7 137.1 1.02% 43 209.5 207.2 -1.10% 48 181.5 170.7 -6.32% 55 130.6 123.8 -5.48% 61 0.014 0.037 62.06% 62 66.7 59.9 -11.36% 68 131.3 127.2 -3.17% 72 567.0 563.4 -0.65% 73 130.1 129.8 -0.29% 88 1044.5 1048.7 0.40% 91 1.2 1.1 -7.93% 96 132.2 131.7 -0.37% As you can see from these results, many queries have a negative speedup ratio, which means that there are negative impacts on the query performance. In query 62, the execution time increased by 11.36%. I guess these regressions are due to the misestimation of the cost in the planner. I attached the execution plan of query 62. The result cache is currently enabled by default. However, if this kind of performance regression is common, we have to change its default behavior. Best regards, Yuya Watari
Вложения
В списке pgsql-hackers по дате отправления: