Re: Track the amount of time waiting due to cost_delay
Sami Imseih <simseih@amazon.com>
From: "Imseih (AWS), Sami" <simseih@amazon.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: 2024-06-28T20:07:39Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add delay time to VACUUM/ANALYZE (VERBOSE) and autovacuum logs.
- 7720082ae532 18.0 landed
-
Add cost-based vacuum delay time to progress views.
- bb8dff9995f2 18.0 landed
-
Add is_analyze parameter to vacuum_delay_point().
- e5b0b0ce1509 18.0 landed
-
Refresh cost-based delay params more frequently in autovacuum
- 7d71d3dd080b 16.0 cited
> 46ebdfe164 will interrupt the leaders sleep every time a parallel workers reports > progress, and we currently don't handle interrupts by restarting the sleep with > the remaining time. nanosleep does provide the ability to restart with the remaining > time [1], but I don't think it's worth the effort to ensure more accurate > vacuum delays for the leader process. After discussing offline with Bertrand, it may be better to have a solution to deal with the interrupts and allows the sleep to continue to completion. This will simplify this patch and will be useful for other cases in which parallel workers need to send a message to the leader. This is the thread [1] for that discussion. [1] https://www.postgresql.org/message-id/01000190606e3d2a-116ead16-84d2-4449-8d18-5053da66b1f4-000000%40email.amazonses.com Regards, Sami