RE: Speedup of relation deletes during recovery

Hello Fujii-san,

On April 18, 2018, Fujii Masao wrote:

> On Fri, Mar 30, 2018 at 12:18 PM, Tsunakawa, Takayuki <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:
>> Furthermore, TRUNCATE has a similar and worse issue. While DROP TABLE
>> scans the shared buffers once for each table, TRUNCATE does that for
>> each fork, resulting in three scans per table. How about changing the
>> following functions
>>
>> smgrtruncate(SMgrRelation reln, ForkNumber forknum, BlockNumber
>> nblocks) DropRelFileNodeBuffers(RelFileNodeBackend rnode, ForkNumber forkNum,
>> BlockNumber firstDelBlock)
>>
>> to
>>
>> smgrtruncate(SMgrRelation reln, ForkNumber *forknum, BlockNumber
>> *nblocks, int nforks) DropRelFileNodeBuffers(RelFileNodeBackend rnode, ForkNumber *forkNum,
>> BlockNumber *firstDelBlock,
>> int nforks)
>>
>> to perform the scan only once per table? If there doesn't seem to be a problem,
>> I think I'll submit the patch next month. I'd welcome if anyone could do that.
>
> Yeah, it's worth working on this problem. To decrease the number of scans of
> shared_buffers, you would need to change the order of truncations of files and WAL
> logging. In RelationTruncate(), currently WAL is logged after FSM and VM are truncated.
> IOW, with the patch, FSM and VM would need to be truncated after WAL logging. You would
> need to check whether this reordering is valid.

I know it's been almost a year since the previous message, but if you could still
recall your suggestion above, I'd like to ask question.
Could you explain your idea a bit further on how would the reordering of WAL writing and
file truncation possibly reduce the number of shared_buffers scan?
Thanks a lot in advance.

Regards,
Kirk Jamison