RE: [PATCH] Speedup truncates of relation forks - Mailing list pgsql-hackers

From Jamison, Kirk
Subject RE: [PATCH] Speedup truncates of relation forks
Date
Msg-id D09B13F772D2274BB348A310EE3027C65147DC@g01jpexmbkw24
Whole thread Raw
In response to RE: [PATCH] Speedup truncates of relation forks  ("Jamison, Kirk" <k.jamison@jp.fujitsu.com>)
Responses Re: [PATCH] Speedup truncates of relation forks  (Fujii Masao <masao.fujii@gmail.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Fetching timeline during recovery
Next
From: Melanie Plageman
Date:
Subject: Re: Memory Accounting