Hi, On Tue, Aug 13, 2024 at 04:30:46PM -0500, Nathan Bossart wrote: > On Tue, Aug 13, 2024 at 01:12:30PM -0500, Imseih (AWS), Sami wrote: > >> None of this seems intractable to me. 1 Hz seems like an entirely > >> reasonable place to start, and it is very easy to change (or to even make > >> configurable). pg_stat_progress_vacuum might show slightly old values in > >> this column, but that should be easy enough to explain in the docs if we > >> are really concerned about it. If other callers want to do something > >> similar, maybe we should add a more generic implementation in > >> backend_progress.c. > >> > > I don't know if I agree. Making vacuum sleep more robust to handle > > interrupts seems like a cleaner general solution than to add > > even more code to handle this case or have to explain the behavior of > > cost delay instrumentation in docs. > > Another concern is the huge number of PqMsg_Progress messages sent by > parallel workers with that approach. In Bertrand's tests, he was seeing > nearly 350K interrupts for a ~19 minute vacuum (~300 interrupts per > second). That seems a bit extreme to me. I don't see how anyone could > possibly need stats about vacuum delays with that level of accuracy. >
I gave it more thoughts and I don't think we have to choose between the two. The 1 Hz approach reduces the number of interrupts and Sami's patch provides a way to get "accurate" delay in case of interrupts. I think both have their own benefit. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
