From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | masao(dot)fujii(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Speedup of relation deletes during recovery |
Date: | 2018-03-30 02:46:31 |
Message-ID: | 20180330024631.GF1368@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 30, 2018 at 11:19:58AM +0900, Kyotaro HORIGUCHI wrote:
> At Fri, 30 Mar 2018 08:31:29 +0900, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote in <CAHGQGwHVQkdfDqtvGVkty+19cQakAydXn1etGND3X0PHbZ3+6w(at)mail(dot)gmail(dot)com>
>> 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.
Yeah, I was just going to say the same after looking at Fujii-san's
patch. This would also cause smgrdounlink() to become unused in the
core code. So this could just be... Removed?
/me Preparing shelter against incoming wraith.
That's not v11 material at this point in any case.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-03-30 03:04:49 | Re: PATCH: Configurable file mode mask |
Previous Message | Peter Geoghegan | 2018-03-30 02:42:42 | Re: [HACKERS] A design for amcheck heapam verification |