Sergey A. Volkov,

лично я против этой идеи, хотя она реализована в InterBase XE3, там есть "ассистенты", которые ресторят индексы параллельно в разных тредах, и их количество рекомендуется устанавливать не больше N-1 от числа ядер процессора.
По умолчанию всегда стоит 1.

Против я потому, что индексы создаются подряд, а создание индекса требует места в temp (создается файл сортировки).
И файл в temp может быть в 6 раз больше, чем индекс занимает в БД (например, для создания индекса в 29 гиг нужен файл в темп размером 182 гиг).
Одно дело, когда индексы создаются последовательно. Но если параллельно, то может получиться так, что при 7ми "ассистентах" эти 7 индексов окажутся самыми жирными в базе, и суммарный размер файлов в temp будет больше, чем размер самой базы.
Таким образом, предсказать необходимое место в temp просто невозможно. И если его не хватит, произойдет облом.
(вот тут я не помню, гбак в версиях выше 2.1 продолжит активировать индексы, или перестанет).
Конечно, раз индексы создаются после рестора данных, и мы знаем количество записей и ширину индексируемых столбцов, можно было бы предположить требуемые размеры файлов сортировки, и выстроить список активируемых индексов так, чтобы при N "ассистентов" объем сортировки был всегда минимально возможным. Но, это ж надо алгоритм какой-то писать.

Кроме того, исходя из низкого параллельного IO на hdd ясно, что какую-то пользу из этого можно было бы извлечь либо на RAID 10 с большим количеством hdd, либо на SSD.

Я так и не удосужился провести такой тест. На IB пробовал, давно, на моем компе (с hdd) полезных результатов это не дало.

Sergey A. VolkovСуществуют утилиты для многопоточной активации индексов? И опыт их использования?
добавлю, что можно самому сделать.
gbak -i и дальше активируй индексы чем хочешь, параллельно или нет.