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.
--
nathan
Fair point. If there is a clear benefit to spacing out the vacuum sleep
delay instrumentation, that could be taken up in that thread. This will
reduce the interrupts, but not eliminate them.
There could still be benefit to ensure that vacuum sleeps can deal
with interrupts and sleep the requested time consistently.
Regards,
Sami
