beduin01

hash индекс строится в один поток, для них многопоточный create index не делали. Потому загрузка 100% одного ядра - ситуация нормальная.
Нет, create index не зависает.
Если у вас селективность поля хреновая - то hash индекс будет строиться медленно, т.к. много строк попадает в одно и то же значение хеширования. Не помню точно, как именно хранится список TID при коллизиях хеш-функции, но точно работает хреново при большом числе дублей значений.

Если версия postgresql достаточно свежая - то смотрите pg_stat_progress_create_index системное представление. Там будут некоторый progress reporting.

function split(arr, numParts) {
  const partSize = arr.length / numParts | 0;

  return Array
    .from({ length: numParts }, (n, i) => i * partSize)
    .map((n, i, a) => arr.slice(n, a[i + 1]));
}

UPD. В комментариях было высказано мнение, что неплохо бы размерам кусков отличаться не более, чем на единицу, т.е., скидывать все "лишние" элементы в последний кусок не надо. Окей, раскидаем сколько можно по одному элементу в разные куски:

function split(arr, numParts) {
  const partSize = arr.length / numParts | 0;
  const numLooseItems = arr.length % numParts;

  return Array.from(
    { length: numParts },
    function(_, i) {
      return arr.slice(this(i), this(i + 1));
    },
    i => i * partSize + Math.min(i, numLooseItems)
  );
}

Можно использовать метаданные маршрутов:

routes: [
  {
    ...
    meta: { pageTitle: 'hello, world!!' },
  },
  {
    ...
    meta: { pageTitle: 'fuck the world' },
  },
  ...
],

<div>{{ $route.meta.pageTitle }}</div>

var result = array.map((v, i) => v - array2[i]);

Хотите проблем - ну делайте "модно-стильно-молодежно". Не хотите проблем - делайте кабелем. wifi был придуман для носимых устройств и оправдан там, где прокладка сети уже невозможна - в старых офисах, на арендуемых площадях, в исторических зданиях.
При проектировании сети всегда стоит закладывать на каждое место на одну розетку больше, чем было посчитано :) Узловые свитчи вязать оптикой. Серверную располагать так, чтобы "чужие здесь не ходят".

Снимите галочку

Ну БД работает через либу юзающую каналы - там уже свой поток, думаю хватит асинхронщины.
Если использовать Moor - то там, вроде, с изолятами все ок.

Когда нужны изоляты:
Есть тяжелая операция и она блочит UI. Ее можно разбить на мелкие асинхронные и поток разгрузится, но может и подтормаживать. Если же нужно распарсить большой JSON - зависаний не избежать.

Вот тут то и можно отдать парсинг в изолят. Можно его не разбивать на асинхронные операции, пусть себе блочит поток - так как этот поток уже будет в новом изоляте (процессе).

Кратко:
Все вычисления что блочат поток можно отдавать в изоляты.
Всякую мелочь не стоит, порой дешевле на Future сделать, но какие-нибудь весомые вещи - да.

Смотря как подключаетесь - по RDP нет, там хоть задвигайтесь мышкой.
Если идет подключение по тимьвьюверу или подобным - то происходит.

Вы пишете какую-то х.ню. Выдумали себе проблему. Если вы хотите избавиться от фонового шума, — вы от него избавляетесь. Если избавиться не получается, — значит вы не хотите от него избавляться. Всё остальное — это отмазки перед самим собой.