Horton

RE: [PATCH] Speedup truncates of relation forks

Jamison, Kirk <k.jamison@jp.fujitsu.com>

View thread
From: "Jamison, Kirk" <k.jamison@jp.fujitsu.com>
To: "Jamison, Kirk" <k.jamison@jp.fujitsu.com>, 'Thomas Munro' <thomas.munro@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Adrien Nayrat <adrien.nayrat@anayrat.info>
Date: 2019-07-24T00:58:24Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Speedup truncations of relation forks.

  2. Remove unused smgrdounlinkfork() function.

  3. Accelerate end-of-transaction dropping of relations

Attachments

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