SanSYS

Какого индекса? Возможно сюрприз, но они сильно разные.

1) PSQL создает индекс в одно-поточном режиме. Это 10% от всей производительности cpu.

psql - это клиент, он вообще не создаёт индексы.
postgresql - начиная с 11 версии умеет многопоточное создание btree. Хотя, наверное, вернее будет сказать сортировку.

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

Не базу, а таблицу. Один раз полный seqscan для create index (с блокировкой записи) или два seqscan для create index concurrently (без блокировки таблицы).
Ничего не сжимает.

3) Из-за того что он медленно перерабатывает данные, он не использует всю скорость ссд на котором расположена база.

Ну смотря какие диски. Дешёвые SSD вполне можно озадачить временными файлами в большом количестве и одним ядром CPU, видел и такое.

Для ускорения построения большого индекса нужна память maintenance_work_mem. Сколько не жалко. 10, 20, 30, 100гб.
На postgresql 11 - плюс настроить число воркеров max_parallel_maintenance_workers, max_worker_processes, max_parallel_workers

но не нашел как их реализовать

Если хотите поучаствовать в разработке самого postgresql - welcome в список рассылок pgsql-hackers. Как делали parallel create index можно почитать по ссылкам с коммита.

Нет.
Та методология является не стандартом и не требованиями, это просто предложение одного разработчика другим и как использовать, использовать в полной мере или только часть, зависит от конкретных желаний конкретной команды.

в настоящий момент пишу инструкции для своих работников

Пишите сами, без участия вашей команды?
Вообще плохая идея писать инструкции по методологиям гита, вам такой вопрос необходимо задать работникам но никак не тут на тостере.

Есть ли более свежая(продвинутая, исправленная и т.д.), модель ветвления?

Нет, в этой теме нет стандартов и без знания вашей модели ведения репозиториев вам никто ничего не подскажет.

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

Всё равно. Технологии из топ 10. Всё быстрое, всё масштабируемое, всё надёжное. Если у девов руки растут из плеч.

Гарантированно производительнее будет так:

$(document).on('click', '.item', (function (e) {
	$('.image', this).text('ok');
});

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

Можно обратить внимание на синтаксис поиска — различные варианты вызова jQuery описаны в документации.

Чего еще можно желать? Я уже готов нанять Вас к себе )
Не уж то Вы хотите устроиться на работу к идиотам, которые требуют 100500 новомодных названий, не понимая, что они значат. Если человек может использовать не свое и может сделать свое, то он лучший из профессионалов.

Единицы измерения забыли дописать у значений перемещения.
Например: left: 15px;
jsfiddle.net/aaorr5pz/1