Hi, On 2022-03-29 12:25:52 +0000, Imseih (AWS), Sami wrote: > > I think that's an absolute no-go. Adding locking to progress reporting, > > particularly a single central lwlock, is going to *vastly* increase the > > overhead incurred by progress reporting. > > Sorry for the late reply. > > The usage of the shared memory will be limited > to PARALLEL maintenance operations. For now, > it will only be populated for parallel vacuums. > Autovacuum for example will not be required to > populate this shared memory.
I nevertheless think that's not acceptable. The whole premise of the progress reporting infrastructure is to be low overhead. It's OK to require locking to initialize parallel progress reporting, it's definitely not ok to require locking to report progress. Leaving the locking aside, doing a hashtable lookup for each progress report is pretty expensive. Why isn't the obvious thing to do here to provide a way to associate workers with their leaders in shared memory, but to use the existing progress fields to report progress? Then, when querying progress, the leader and workers progress fields can be combined to show the overall progress? Greetings, Andres Freund