I’ve got an older DB (postgres 10.15) that’s not yet been upgraded. One problematic table had a few large indexes on it, some of which were corrupt and needed reindexing. Since it’s not on version 12+, I can’t concurrently reindex the table (which means I need to do it non-concurrently, which requires a table write lock) – so I wanted to know how I could do some rough calculations on how long the reindex would take so I can plan some maintenance. Most of my research ends up in the "just use pg_stat_progress_create_index! (which isn’t available in 10), or people just saying to use CONCURRENTLY.
The table is ~200GB, and there are indexes are 7 indexes which are 14GB each (as per pg_relation_size). I can get ~900M/s constant read-rate on the DB for this task. Is there a simple metric I can use to determine how much data will be required to be read to reindex fully?