| От | Jamison, Kirk |
|---|---|
| Тема | RE: [PATCH] Speedup truncates of relation forks |
| Дата | |
| Msg-id | D09B13F772D2274BB348A310EE3027C65147DC@g01jpexmbkw24 обсуждение |
| Ответ на | RE: [PATCH] Speedup truncates of relation forks ("Jamison, Kirk" <k.jamison@jp.fujitsu.com>) |
| Ответы |
Re: [PATCH] Speedup truncates of relation forks
|
| Список | pgsql-hackers |
Hi,
I repeated the recovery performance test before, and found out that I made a
wrong measurement.
Using the same steps indicated in the previous email (24GB shared_buffers for my case),
the recovery time still significantly improved compared to head
from "13 minutes" to "4 minutes 44 seconds" //not 30 seconds.
It's expected because the measurement of vacuum execution time (no failover)
which I reported in the first email is about the same (although 5 minutes):
> HEAD results
> 3) 24GB shared_buffers = 14 min 13.598 s
> PATCH results
> 3) 24GB shared_buffers = 5 min 35.848 s
Reattaching the patch here again. The V5 of the patch fixed the compile error
mentioned before and mainly addressed the comments/advice of Sawada-san.
- updated more accurate comments describing only current behavior, not history
- updated function name: visibilitymap_truncate_prepare()
- moved the setting of values for smgr_{fsm,vm}_nblocks inside the smgrtruncate()
I'd be grateful if anyone could provide comments, advice, or insights.
Thank you again in advance.
Regards,
Kirk Jamison
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера