Ну, вы же понимаете, что построение индекса с нуля для уже существующей таблицы подобных размеров - это операция нестандартная, в общем-то. Не думали партиционировать данные?
И да, постгрес умеет строить индексы многопоточно:
PostgreSQL can build indexes while leveraging multiple CPUs in order to process the table rows faster. This feature is known as parallel index build. For index methods that support building indexes in parallel (currently, only B-tree), maintenance_work_mem specifies the maximum amount of memory that can be used by each index build operation as a whole, regardless of how many worker processes were started. Generally, a cost model automatically determines how many worker processes should be requested, if any.
https://www.postgresql.org/docs/11/sql-createindex.html
З.Ы. - ещё могу добавить, что с такими здоровыми индексами в целом неудобно работать, так что построение - это только первая проблема. Чем больше индекс, тем затратнее будет каждый инсерт/апдейт по этой таблице из-за его перестройки. Ну и, конечно, на определённом этапе индекс может просто перестать помещаться в память - это тоже не ок.
