Option to VACUUM instead of just ANALYZE after a large database change?

[jamadden]

When a GC completes, RelStorage tells the adapter that "a large database change" has taken place, and the adapter is supposed to take steps that are necessary to optimize performance after that change, for example, update database statistics.

For a brief period of time (code that I don't think was actually release), RelStorage/PostgreSQL ran VACUUM(ANALYZE), which collects statistics and performs dead tuple elimination. In d25a019 that was changed to just ANALYZE to avoid "a read table lock."

However, the documentation back to 9.6 claims that:

[T]he standard form of VACUUM can run in parallel with production database operations. (Commands such as SELECT, INSERT, UPDATE, and DELETE will continue to function normally, though you will not be able to modify the definition of a table with commands such as ALTER TABLE while it is being vacuumed.)

So I'm not sure what I was seeing and that should be investigated. At the very least, it would be nice to have the option to VACUUM instead of just ANALYZE so administrators only have to schedule one job (if they can tolerate a possible lock).