From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | "Imseih (AWS), Sami" <samimseih(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Restart pg_usleep when interrupted |
Date: | 2024-08-13 21:30:46 |
Message-ID: | ZrvQhkrqFrLbu4kl@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-08-13 21:46:34 | Re: Remove dependence on integer wrapping |
Previous Message | Kirill Reshke | 2024-08-13 21:15:01 | Re: CSN snapshots in hot standby |