Re: Speedup of relation deletes during recovery - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Speedup of relation deletes during recovery
Date
Msg-id 20180330.111958.152181145.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Speedup of relation deletes during recovery  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Speedup of relation deletes during recovery  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Hello.

At Fri, 30 Mar 2018 08:31:29 +0900, Fujii Masao <masao.fujii@gmail.com> wrote in
<CAHGQGwHVQkdfDqtvGVkty+19cQakAydXn1etGND3X0PHbZ3+6w@mail.gmail.com>
> Hi,
> 
> When multiple relations are deleted at the same transaction,
> the files of those relations are deleted by one call to smgrdounlinkall(),
> which leads to scan whole shared_buffers only one time. OTOH,
> during recovery, smgrdounlink() (not smgrdounlinkall()) is called
> for each file to delete, which leads to scan shared_buffers multiple times.
> Obviously this can cause to increase the WAL replay time very much
> especially when shared_buffers is huge.
> 
> To alleviate this situation, I'd like to propose to change the recovery
> so that it also calls smgrdounlinkall() only one time to delete multiple
> relation files. Patch attached. Thought?

It is obviously a left-over of 279628a0a7. This patch applies the
same change with the patch and looks fine for me. Note that
FinishPreparedTransaction has the same loop over smgrdounlink.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Edmund Horner
Date:
Subject: Re: pgbench doc typos
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Protect syscache from bloating with negative cache entries