On Friday, December 11, 2020 10:27 AM, Amit Kapila wrote: > On Fri, Dec 11, 2020 at 5:54 AM k.jami...@fujitsu.com > <k.jami...@fujitsu.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
v35-0001-Prevent-invalidating-blocks-in-smgrextend-during.patch
Description: v35-0001-Prevent-invalidating-blocks-in-smgrextend-during.patch
v35-0002-Add-bool-param-in-smgrnblocks-for-cached-blocks.patch
Description: v35-0002-Add-bool-param-in-smgrnblocks-for-cached-blocks.patch
v35-0003-Optimize-DropRelFileNodeBuffers-during-recovery.patch
Description: v35-0003-Optimize-DropRelFileNodeBuffers-during-recovery.patch
v35-0004-Optimize-DropRelFileNodesAllBuffers-in-recovery.patch
Description: v35-0004-Optimize-DropRelFileNodesAllBuffers-in-recovery.patch
