Melkij

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

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 можно почитать по ссылкам с коммита.

Скопируйте весь /var/lib/mysql/ и запустите базу, лучше той же major версии, поглядывая за логом.

where 'ct_head_short' like template
seqscan ожидаемо, но для малого числа строк работать будет

Взять выборку и обернуть во второй select с обратной сортировкой.

select fields,... from (
select fields,... from tablename order by field desc limit 30
) as subquery
order by field limit 30

Впрочем, если подумать:

(
select fields,... from tablename order by field desc limit 30
)
order by field limit 30

mysql умеет

А где тут ошибки нет?
В теге указан postgresql, где синтаксис create database вот такой: https://www.postgresql.org/docs/current/sql-create...

А ваш запрос как раз начиная со слова on никак не похож и явно от какой-то другой СУБД.

Начал писать комментарий про вот уже скоро 20 лет существования http/1.1, но впрочем всё чуть проще:

https://tools.ietf.org/html/rfc2616#section-14.23

A client MUST include a Host header field in all HTTP/1.1 request messages

Вы грубо нарушили стандарт. Вы представились как HTTP/1.1 клиент, но не передали требуемый для этого стандарта заголовок Host.
Некорректный запрос клиента - это код 400, сервер вам отвечает корректно.

Минимально возможный запрос для HTTP/1.1 - это две строки:

GET /... HTTP/1.1
Host: api.vk.com

Возможно потребуются ещё какие-нибудь заголовки, но это уже по необходимости. Браузеры типично отправляют много дополнительных заголовков.

Одна строка была давным-давно допустима для HTTP/1.0, где на одном IP мог быть максимум 1 сайт. Большинство современных серверов вас выслушают по HTTP/1.0 но вряд ли вернут то что вы хотите, т.к. не будут знать, о каком домене вы спрашиваете и соответственно какому обработчику передавать запрос.

Что такое include?

чтобы в найденные объекты Lead добавлялись поля Unit, основываясь на unitId.

Банальный join.

Аккаунт ОС не имеет никакого отношения к пользователю БД. База может быть настроена проверять подлинность пользователя по соответствию имени пользователя - peer для unix sock. Но это не обязательно и это единственное что может связывать пользователя ОС и базу. (кроме учётки владельца, у того есть доступ напрямую к файлам)

Но пользователь базы должен уже существовать. А раз вам нужно создать сперва пользователя - то тогда же создайте и базу для него.

Далее следует сказать, что рядовой пользователь вовсе не может создавать базы данных. Это право должно быть выдано явно.
Подключиться к postgresql можно только к конкретной уже существующей БД и у вашего пользователя должны быть права как на прохождение аутентификации указанным в hba методом так и права на подключение к нужной базе.

archive_command = '/usr/local/bin/backup_wal.sh'

cat /usr/local/bin/backup_wal.sh
#!/bin/bash

. /etc/wal-g.d/server-s3.conf

wal-g backup-push /var/lib/pgsql/9.6/
wal-g backup-list

Аааа?... Это вы сейчас серьёзно?

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

wal-push в archive_command должен быть. backup-push отдельно, из крона обычно.

См. механизм cgroups.
Крутилки для io там были, например: https://unix.stackexchange.com/q/48138

mysql давным давно умеет backward index scan.

select * from events order by event_date desc limit 10
select * from events order by event_date asc limit 10

Оба могут использовать индекс по event_date.

Начиная с 8.0 вы даже можете указать направление сортировки индекса и самостоятельно. ASC и DESC в определении индекса больше не игнорируются.

Чем вам поможет KVM, да и любая виртуализация в принципе, если софтинку убить нельзя, а она объедается памяти без ограничений? Всё равно OOM будет.

Настройка сети KVM для вашего случая ничем не отличается, даёте ей один vif подцепленный на br1 и 10.0.0.250/24 в качестве default gateway. Кроме разве что того, что настройки IP адресации вам надо указывать в самом госте. Ну или dhcp настроить.