The implementation for ModifyColumnMigration uses a VACUUM step but this is done at "full speed", and it should ideally be slowed down so that it does not overwhelm the database being operated on.
This can be achieved using Cost-based Vacuum Delay (Note: the documentation's introductory paragraph to those PostgreSQL parameters are worth reading). In particular vacuum_cost_delay needs to be non-zero to enable this feature on a manual VACUUM (for clarity: and that is what we are doing in the implementation).
Chatting to @marco44, these values should ideally be inferred from the table's equivalent autovacuum_* values, as these are assumed to be safe (in terms of low risk of DB performance degradation). However, they can be -1 (which implies using the vacuum_* values instead) and so this needs to be checked rather than blindly copied.
The implementation for
ModifyColumnMigrationuses aVACUUMstep but this is done at "full speed", and it should ideally be slowed down so that it does not overwhelm the database being operated on.This can be achieved using Cost-based Vacuum Delay (Note: the documentation's introductory paragraph to those PostgreSQL parameters are worth reading). In particular
vacuum_cost_delayneeds to be non-zero to enable this feature on a manualVACUUM(for clarity: and that is what we are doing in the implementation).Chatting to @marco44, these values should ideally be inferred from the table's equivalent
autovacuum_*values, as these are assumed to be safe (in terms of low risk of DB performance degradation). However, they can be-1(which implies using thevacuum_*values instead) and so this needs to be checked rather than blindly copied.