RE: [PATCH] Speedup truncates of relation forks
Jamison, Kirk <k.jamison@jp.fujitsu.com>
From: "Jamison, Kirk" <k.jamison@jp.fujitsu.com>
To: 'Fujii Masao' <masao.fujii@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Thomas Munro <thomas.munro@gmail.com>, 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-09-17T01:44:12Z
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 →
-
Speedup truncations of relation forks.
- 6d05086c0a79 13.0 landed
-
Remove unused smgrdounlinkfork() function.
- 33a94bae605e 13.0 landed
-
Accelerate end-of-transaction dropping of relations
- 279628a0a7cf 9.3.0 cited
Attachments
- v1-0001-Remove-deadcode-smgrdounlinkfork.patch (application/octet-stream) patch v1-0001
- v8-0001-Speedup-truncates-of-relation-forks.patch (application/octet-stream) patch v8-0001
On Friday, September 13, 2019 10:06 PM (GMT+9), Fujii Masao wrote: > On Fri, Sep 13, 2019 at 9:51 PM Alvaro Herrera <alvherre@2ndquadrant.com> > wrote: > > > > On 2019-Sep-13, Fujii Masao wrote: > > > > > On Mon, Sep 9, 2019 at 3:52 PM Jamison, Kirk <k.jamison@jp.fujitsu.com> > wrote: > > > > > > > Please add a preliminary patch that removes the function. Dead > > > > > code is good, as long as it is gone. We can get it pushed ahead of > the rest of this. > > > > > > > > Alright. I've attached a separate patch removing the smgrdounlinkfork. > > > > > > Per the past discussion, some people want to keep this "dead" > > > function for some reasons. So, in my opinion, it's better to just > > > enclose the function with #if NOT_USED and #endif, to keep the > > > function itself as it is, and then to start new discussion on > > > hackers about the removal of that separatedly from this patch. > > > > I searched for anybody requesting to keep the function. I couldn't > > find anything. Tom said in 2012: > > https://www.postgresql.org/message-id/1471.1339106082@sss.pgh.pa.us > > Yes. And I found Andres. > https://www.postgresql.org/message-id/20180621174129.hogefyopje4xaznu@al > ap3.anarazel.de > > > > As committed, the smgrdounlinkfork case is actually dead code; it's > > > never called from anywhere. I left it in place just in case we want > > > it someday. > > > > but if no use has appeared in 7 years, I say it's time to kill it. > > +1 The consensus is we remove it, right? Re-attaching the patch that removes the deadcode: smgrdounlinkfork(). --- I've also fixed Fujii-san's comments below in the latest attached speedup truncate rel patch (v8). > Here are other comments for the latest patch: > > + block = visibilitymap_truncate_prepare(rel, 0); if > + (BlockNumberIsValid(block)) fork = VISIBILITYMAP_FORKNUM; > + > + smgrtruncate(rel->rd_smgr, &fork, 1, &block); > > If visibilitymap_truncate_prepare() returns InvalidBlockNumber, > smgrtruncate() should not be called. > > + FreeSpaceMapVacuumRange(rel, first_removed_nblocks, > + InvalidBlockNumber); Thank you again for the review! Regards, Kirk Jamison