Hi Jonathan. Do you want change proposals here as text snippets in emails? It seems the patch process isn't used here.
If so, here's an attempted reduction that echoes what Robert said. I also thought explaining Vacuum wouldn't be necessary for this audience, so less lead-in could work. Is the benefit to end users that there is less memory and CPU needed by vacuum, thus more CPU and memory is available to their foreground workload?
Original:
> A foundational feature of PostgreSQL is [vacuum](https://www.postgresql.org/docs/17/routine-vacuuming.html), which is used to reclaim storage from data that was marked as removed. Reducing resources required for vacuuming directly helps other areas of PostgreSQL, particularly on very busy systems. PostgreSQL 17 introduces a new internal memory structure for vacuum that's shown up to a 20x reduction in memory and improvements in overall vacuuming speed.
Proposed:
The PostgreSQL [vacuum](
https://www.postgresql.org/docs/17/routine-vacuuming.html) process is critical for healthy operations, requiring server instance resources to operate. With PostgreSQL 17, a new internal memory structure for vacuum was used that consumes up to 20x less memory. This improves vacuum speed and also reduces the use of shared resources, making more available for your workload.
Something along those lines, where the benefit to the user is they could expect more CPU/mem etc. available for their SQL operations, right? This could be something folks want to benchmark as well as a reason to upgrade, at least for Vacuum-intensive workloads, high UPDATE and DELETE operations etc.