Re: [Patch] Optimize dropping of relation buffers using dlist - Mailing list pgsql-hackers

From Zhihong Yu
Subject Re: [Patch] Optimize dropping of relation buffers using dlist
Date
Msg-id CALNJ-vRt-eFodxKhn_PxLHPaWxEUiVOWCpeOpJGYx_BL=4gEvQ@mail.gmail.com
Whole thread Raw
In response to RE: [Patch] Optimize dropping of relation buffers using dlist  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
List pgsql-hackers
Hi,
It is possible to come out of the nested loop without goto.

+   bool        cached = true;
...
+    * to that fork during recovery.
+    */
+   for (i = 0; i < n && cached; i++)
...
+           if (!cached)
+.              break;

Here I changed the initial value for cached to true so that we enter the outer loop.
In place of the original goto, we break out of inner loop and exit outer loop.

Cheers

On Tue, Dec 22, 2020 at 8:22 PM tsunakawa.takay@fujitsu.com <tsunakawa.takay@fujitsu.com> wrote:
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.)


Regards
Takayuki Tsunakawa




pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Reduce the number of special cases to build contrib modules on windows
Next
From: Konstantin Knizhnik
Date:
Subject: Re: libpq compression