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 https://github.com/zodb/relstorage/commit/d25a019e2816c4e974e2041589e5b7ff3e0a4adc that was changed to just ANALYZE to avoid "a read table lock."
[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).
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 https://github.com/zodb/relstorage/commit/d25a019e2816c4e974e2041589e5b7ff3e0a4adc that was changed to justANALYZEto avoid "a read table lock."However, the documentation back to 9.6 claims that:
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
VACUUMinstead of justANALYZEso administrators only have to schedule one job (if they can tolerate a possible lock).