RE: [Patch] Optimize dropping of relation buffers using dlist

On Friday, December 11, 2020 10:27 AM, Amit Kapila wrote:
> On Fri, Dec 11, 2020 at 5:54 AM k(dot)jamison(at)fujitsu(dot)com
> <k(dot)jamison(at)fujitsu(dot)com> wrote:
> > So should I still not include that information?
> >
>
> I think we can extend your existing comment like: "Otherwise if the size of a
> relation fork is not cached, we proceed to a full scan of the whole buffer pool.
> This can happen if there is no update to a particular fork during recovery."

Attached are the final updated patches.
I followed this advice and updated the source code comment a little bit.
There are no changes from the previous except that and the unnecessary
"cached" condition which Tsunakawa-san mentioned.

Below is also the updated recovery performance test results for TRUNCATE.
(1000 tables, 1MB per table, results measured in seconds)
| s_b | Master | Patched | % Reg |
|-------|--------|---------|---------|
| 128MB | 0.406 | 0.406 | 0% |
| 512MB | 0.506 | 0.406 | -25% |
| 1GB | 0.806 | 0.406 | -99% |
| 20GB | 15.224 | 0.406 | -3650% |
| 100GB | 81.506 | 0.406 | -19975% |

Because of the size of relation, it is expected to enter full-scan for
the 128MB shared_buffers setting. And there was no regression.
Similar to previous test results, the recovery time was constant
for all shared_buffers setting with the patches applied.

Regards,
Kirk Jamison