On Fri, Jul 12, 2024 at 02:21:09PM +0900, Michael Paquier wrote: > On Thu, Jul 11, 2024 at 08:50:57PM -0500, Nathan Bossart wrote: >> I'm not following how this is guaranteed to trigger an autovacuum quickly. >> Shouldn't we set autovacuum_vacuum_insert_threshold to 1 so that it is >> eligible for autovacuum? > > You are right, this is not going to influence a faster startup of a > worker, so we could remove that entirely. On closer look, the main > bottlebeck is that the test is spending a lot of time waiting on the > naptime even if we are using the minimum value of 1s, as the scan of > pg_stat_activity checking for workers keeps looping.
I suppose it would be silly to allow even lower values for autovacuum_naptime (e.g., by moving it to ConfigureNamesReal and setting the minimum to 0.1). > I have one trick in my sleeve for this one to make the launcher more > responsive in checking the timestamps of the database list. That's > not perfect, but it reduces the wait behind the worker startups by > 400ms (1s previously as of the naptime, 600ms now) with a reload to > set the launcher's latch after the injection point has been attached. > The difference in runtime is noticeable. That's a neat trick. I was confused why this test generates an autovacuum worker at all, but I now see that you are pausing it before we even gather the list of tables that need to be vacuumed. >> Is it worth testing cancellation, too? > > The point is to check after pg_signal_backend, so I am not sure it is > worth the extra cycles for the cancellation. Agreed. > What do you think? Looks reasonable to me. -- nathan
