Melkij

Поиск точного вхождения подстроки в строку? LIKE '%...%'
Плюс триграммный индекс из pg_trgm contrib

INSERT INTO `city` (`country_id`, `region_id`, `title`) VALUES (109, 0, 'Москва')

А вот если вы попробуете писать NULL вместо вот этого - то всё получится и именно так FK и работает, допуская использование NULL.

1) Можно ли создать логическую репликацию на уровне схемы

Нет.
Ответ есть даже в мануале: https://www.postgresql.org/docs/10/sql-createpubli...
Банально нет даже синтаксиса для создания публикации схемы.

2) Связи между таблицами также будут реплицыроватся?

Что вы имеете в виду?
DDL вы переносите на подписчиков сами. Реплицируются только данные

TRUNCATE and DDL operations are not published.

truncate начали реплицировать в pg11. Репликации DDL нет и не будет как минимум ещё в pg12, на данный момент нет ни черновых патчей ни даже обсуждений таковой реализации.

То есть так, как вы, видимо, хотите настроить паблишера и он сам всем будет заниматься - не выйдет.

PS: есть некоторая терминологическая путаница, как англоязычная так и русскоязычная, schema и схема как namespace или schema и схема говоря о структуре базы, т.е. DDL

Если задумку реализовать корректно - то эквивалентны. Должны быть. У вас пока не эквивалентны, потому что

melkij=> select '\uFFFF';
 ?column? 
----------
 \uFFFF

Так unicode escapes не пишутся. E'\uFFFF'

Хотя обычно берут штатный text_pattern_ops и like работает нормально.

Вы должны разрабатывать и деплоить приложение соответствующим образом. Так, чтобы старая версия приложения могла работать с новой версией схемы базы. Или наоборот, новая версия приложения могла работать со старой схемой базы.
То есть удаление таблички: сначала деплоите приложение, которое уже не работает с этой таблицей, потом удаляете таблицу
Новая табличка: сначала миграция, затем приложение
Новое поле в таблице с default значением: сначала поле, затем приложение
Новое поле без default: сначала новое поле с default null, затем релиз приложения которое обязано писать новое поле, но ещё не читать его (либо приводить null к нужному если это возможно на приложении), затем миграция с проставлением нужного значения (и, блин, не одним update по всей большой таблице), drop default, set not null, деплой приложения со всей логикой
И так далее. Во время разработки думаем, а как, когда и в сколько итераций это можно будет задеплоить.

Ну и, разумеется, DBA (или заменяющий его обязанности человек) думает над тем, как именно вносить нужную миграцию в базу

А сколько у вас ядер на железке, чтобы пускать параллельно 1000 запросов? Хотя бы сотня ядер CPU под такое есть, чтобы за каждое ядро дрались и мешали друг другу всего десяток процессов?

Если хотите снизить латентность - сохраняйте уже открытые соединения.
Если хотите повысить пропускную способность - уменьшайте число активных процессов.
Очень сильно лучше и то и другое сразу. Поэтому да, pgbouncer. Или хотя бы разумных размеров пул на приложении.

Нет, такого нет. Потому что непонятно зачем нужно.

Если сможете аргументированно указать сообществу, что такая штука зачем-то нужна - welcome. Потом найти заинтересованного разработчика (ну или самостоятельно), кто возьмётся за обсуждение пользовательского интерфейса, напишет патч и доведёт его до согласия с как минимум одним коммитером при отсутствии резких возражений от остальных участников сообщества.
Сейчас готовится pg12, никаких обсуждений планировщиков задач нет. Поэтому маловероятно, что появится и в pg13 релизе.

Планировщик Postgresql на данный момент не умеет loose index scan. Поэтому планировщик вполне обоснованно со своей точки зрения выбирает не использовать какие-либо индексы.

Поэтому если необходим именно distinct по не очень селективному полю - то эффективнее объяснить планировщику что от него хотят руками: https://wiki.postgresql.org/wiki/Loose_indexscan

Вам же скорее необходимо менять схему хранения данных.

Возможно в самом запросе нужно явно указать, чтобы использовался индекс. Как это сделать в PostgreSQL?Возможно в самом запросе нужно явно указать, чтобы использовался индекс. Как это сделать в PostgreSQL?

Никак. Сообщество сознательно PostgreSQL отказывается добавлять какие-либо хинты планировщика, предпочитая узнавать об ошибках планировщика как о багах и по возможности их исправлять.

Можно я сошлюсь на своё сочинение на SO? https://ru.stackoverflow.com/q/721985/203622

Впрочем пару слов добавлю:

добавив к примеру столбец

Важно какой именно. Если default null - просто берёте и добавляете со statement_timeout в 1 секунду. alter table всё равно возьмёт блокировку на таблицу, но default null поле - это лишь быстрое обновление системного каталога.
Если другой default - то для pg11 просто берёте и добавляете с таймаутом, для более старых немного приключений.

Если у вас нормальные SSD (а для hetzner это надо отдельно выяснять - могут откровенный мусор поставить под видом datacenter ssd) - то вам вообще не нужен RAID-контроллер.
Разве только вы умеете конкретно этот контроллер аккуратно настраивать под работу с SSD. Иначе вы упрётесь в производительность контроллера, а не в возможности накопителей. RAID контроллеры уже давно не успевают за хорошими SSD

с помощью утилиты pgsql

Не знаю таких. Что это за утилита, что делает, как это делает?

что значит \.

Так помечается конец данных для COPY. https://www.postgresql.org/docs/current/sql-copy.html

End of data can be represented by a single line containing just backslash-period (\.).

емнип, php вовсе не может выполнять copy from stdin как запросы, только как функции PDO::pgsqlCopyFromArray для PDO или pg_put_line, pg_end_copy для php-postgresql расширения.

apt-get install --no-install-recommends libvirt-clients python-libvirt

kvm и qemu в рекомендуемых пакетах упомянуты, установка которых обычно включена

Сначала сделать copy в другую табличку с текстовыми полями (temporary table вполне подходящее место), затем insert .. select запросом перенести куда надо с любыми манипуляциями по пути.

Или сделать хранимку на любом языке и читать файл через неё, преобразуя данные по пути.