On Wed, Apr 1, 2026 at 2:43 PM Daniil Davydov <3danissimo@gmail.com> wrote:
>
> Hi,
>
> On Thu, Apr 2, 2026 at 1:55 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > Overall, the results show no noticeable overhead from the polling approach.
>
> Great news! Thank you for these measurements!
>
> BTW, I caught myself thinking that Tom Lane and maybe some other people might
> not like our parameter propagation logic. We are not building any new
> capability, but supplying an utilitarian solution for a single feature.
> Perhaps someone will not consider this a good way to develop new features.
Agreed, this is the one of the reasons why I summarized and conducted
the performance evaluation.
I've also experimented with the idea of using proc signal to propagate
the vacuum delay parameters update. The attached patch can be aplied
on top of v36 patch. While it requires adding a new function to
parallel.c and requires a bit more codes, it uses the exisiting
infrastructure for the propagation. Given that this propagation logic
works only when parallel vacuum workers are running, testing the
propagation logic in TAP tests using injection points becomes
complicated, so I removed. What do you think about this idea?
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
