Re: [Patch] Optimize dropping of relation buffers using dlist
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: tsunakawa.takay@fujitsu.com
Cc: amit.kapila16@gmail.com, andres@anarazel.de, k.jamison@fujitsu.com,
tgl@sss.pgh.pa.us, thomas.munro@gmail.com, robertmhaas@gmail.com,
tomas.vondra@2ndquadrant.com, pgsql-hackers@postgresql.org
Date: 2020-12-23T05:12:41Z
Lists: pgsql-hackers
At Wed, 23 Dec 2020 04:22:19 +0000, "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com> wrote in > From: Amit Kapila <amit.kapila16@gmail.com> > > + /* Get the number of blocks for a relation's fork */ > > + block[i][j] = smgrnblocks(smgr_reln[i], j, &cached); > > + > > + if (!cached) > > + goto buffer_full_scan; > > > > Why do we need to use goto here? We can simply break from the loop and > > then check if (cached && nBlocksToInvalidate < > > BUF_DROP_FULL_SCAN_THRESHOLD). I think we should try to avoid goto if > > possible without much complexity. > > That's because two for loops are nested -- breaking there only exits the inner loop. (I thought the same as you at first... And I understand some people have alergy to goto, I think modest use of goto makes the code readable.) I don't strongly oppose to goto's but in this case the outer loop can break on the same condition with the inner loop, since cached is true whenever the inner loop runs to the end. It is needed to initialize the variable cache with true, instead of false, though. The same pattern is seen in the tree. Regards. -- Kyotaro Horiguchi NTT Open Source Software Center
Commits
-
Fix size overflow in calculation introduced by commits d6ad34f3 and bea449c6.
- 519e4c9ee21a 14.0 landed
-
Optimize DropRelFileNodesAllBuffers() for recovery.
- bea449c635c0 14.0 landed
-
Optimize DropRelFileNodeBuffers() for recovery.
- d6ad34f3410f 14.0 landed
-
Cache smgrnblocks() results in recovery.
- c5315f4f4484 14.0 cited
-
Add a check to prevent overwriting valid data if smgrnblocks() gives a
- ffae5cc5a602 8.2.0 cited