Melkij

Динамические (вычисляемые) колонки в mysql есть начиная с 5.7 ветки: https://dev.mysql.com/doc/refman/5.7/en/create-tab...

Бывают virtual - вычисляются при обращении, бывают stored - вычисляются перед записью и хранятся на диске.

vacuum - запустить vacuum. В нём нет ничего страшного, если вы не отстрелили себе ноги, то база сама его запускает согласно настройкам.

vacuum full - история очень сильно отдельная, т.к. это ни разу не vacuum.
Места под vacuum full надо под копию таблицы с индексами и на запись этой копии в WAL. То есть теоретически до двукратного объёма.
Поскольку для рабочей базы возможность уйти на сколько-то часов штука неинтересная - vacuum full по большим таблицам не делают.
Есть pg_repack делающий с помощью триггера и чёрной магии копию таблицы (место всё так же нужно свободное), после накатывает изменения в основной таблице и заменяет основную на свежую копию. В целом - то что делает vacuum full, но без тяжёлой блокировки таблицы.
Есть pgcompacttable, идущий другим путём. postgresql пытается новые строки размещать в начале таблицы, поэтому фиктивные обновления строк в конце таблицы скорей всего переместятся в начало, а пустые страницы в конце может срезать обычный vacuum. Плюс перестроить индексы (правда не все). Обновление inplace, запас места под копию не требуется. Полную блокировку таблицы конечно тоже не берём.

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

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 но вряд ли вернут то что вы хотите, т.к. не будут знать, о каком домене вы спрашиваете и соответственно какому обработчику передавать запрос.