Re: autovacuum: automatically propagate updated parameters

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Subject: Re: autovacuum: automatically propagate updated parameters
Date: 2026-09-25 08:41:08
Message-ID: 8B81FC42-44FB-474C-A3B0-2593F44C4996@yesql.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> On 25 Sep 2026, at 09:45, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
>
> On Thu, 24 Sep 2026, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>> So if we want to
>> use the condition variable, it seems better to me to have a dedicated
>> wait function in vacuumparallel.c that waits until all indexes are
>> completed, and then call WaitForParallelWorkersToFinish().
>
> That'll bring back the more complicated approach of v2, and also make
> this part of the code more complex.

I think that would be cleaner, but also more invasive at post-beta4.

> While I didn't do proper measurements, my logic against it was similar
> to what Manu already posted, that it seems harmless here and it is
> significantly simpler than adding a cv.
>
> Also, I think both issues could be solved in a more proper way with
> more refactoring, but that seems excessive for 19. (And in that case,
> going with a simple solution for 19 also seems like a good answer to
> me)

Given where we are in the cycle I am also in favor of a simpler solution unless
it's shown to have (severe) performance regressions.

--
Daniel Gustafsson

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Palak Chaturvedi 2026-09-25 09:09:41 Re: BUG #19701: GIN trigram index loses rows at similarity_threshold 0
Previous Message Zsolt Parragi 2026-09-25 07:45:17 Re: autovacuum: automatically propagate updated parameters