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

From: Jamison, Kirk/ジャミソン カーク <k.jamison@fujitsu.com>
> 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.
What's the change in bufmgr.c for?  Is it to be included in 0001 or 0002?


> 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
niceto shorten this long time. 

I'll review the patch soon.


Regards
Takayuki Tsunakawa