On Thursday, October 22, 2020 10:34 AM, Tsunakwa-san wrote:
> > I have confirmed that the above comment (commenting out the lines in
> > RelationTruncate) solves the issue for non-recovery case.
> > The attached 0004 patch is just for non-recovery testing and is not
> > included in the final set of patches to be committed for vacuum
> optimization.
>
> I'm relieved to hear that.
>
> As for 0004:
> When testing TRUNCATE, remove the change to storage.c because it was
> intended to troubleshoot the VACUUM test.
I've removed it now.
> What's the change in bufmgr.c for? Is it to be included in 0001 or 0002?
Right. But that should be in 0003. Fixed.
I also fixed the feedback from the previous email:
>(1)
>+ * as the total nblocks for a given fork. The cached value returned by
>
>nblocks -> blocks
> > The table below shows the vacuum execution time for non-recovery case.
> > I've also subtracted the execution time when VACUUM (truncate off) is set.
> >
> > [NON-RECOVERY CASE - VACUUM execution Time in seconds]
> (snip)
> > | 100GB | 65.456 | 1.795 | -3546.57% |
>
> So, the full shared buffer scan for 10,000 relations took about as long as 63
> seconds (= 6.3 ms per relation). It's nice to shorten this long time.
>
> I'll review the patch soon.
Thank you very much for the reviews. Attached are the latest set of patches.
Regards,
Kirk Jamison