Re: [Patch] Optimize dropping of relation buffers using dlist
| От | Zhihong Yu |
|---|---|
| Тема | Re: [Patch] Optimize dropping of relation buffers using dlist |
| Дата | |
| Msg-id | CALNJ-vRt-eFodxKhn_PxLHPaWxEUiVOWCpeOpJGYx_BL=4gEvQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | RE: [Patch] Optimize dropping of relation buffers using dlist ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>) |
| Список | 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++)
+ */
+ 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
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 по дате отправления: