RE: [PATCH] Speedup truncates of relation forks

Поиск
Список
Период
Сортировка
От 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  (Fujii Masao <masao.fujii@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Fetching timeline during recovery
Следующее
От: Melanie Plageman
Дата:
Сообщение: Re: Memory Accounting