From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Speedup of relation deletes during recovery |
Date: | 2018-04-18 16:52:26 |
Message-ID: | CAHGQGwGOYj=5+rAsUoL--o0-pgM47yvee_mpPQ8G0fzOVTGzKA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 18, 2018 at 10:44 AM, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Wed, Apr 18, 2018 at 12:46:58AM +0900, Fujii Masao wrote:
>> Yes, I think. And, I found that smgrdounlinkfork() is also dead code.
>> Per the discussion [1], this unused function was left intentionally.
>> But it's still dead code since 2012, so I'd like to remove it. Patch attached.
>
> Indeed, it's close to six years and the status is the same. So let's
> drop it. I have been surrounding the area to see if any modules
> actually use those, particularly on github, but I could not find
> callers.
>
> The patch looks logically fine to me. In your first message, you
> mentioned that the replay time increased a lot. Do you have numbers to
> share with some large settings of shared_buffers?
No. But after my colleague truncated more than one hundred tables on
the server with shared_buffers = 300GB, the recovery could not finish
even after 10 minutes since the startup of the recovery. So I had to
shutdown the server immediately, set shared_buffers to very small
temporarily and start the server to cause the recovery to finish soon.
> It would be better to wait for v12 branch to open before pushing
> anything, as the focus is on stabililizing things on v11.
Yes, so I added this to next CommitFest.
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-04-18 17:02:38 | Re: Query is over 2x slower with jit=on |
Previous Message | Chapman Flack | 2018-04-18 16:50:48 | Re: Query is over 2x slower with jit=on |