Melkij

Вы должны разрабатывать и деплоить приложение соответствующим образом. Так, чтобы старая версия приложения могла работать с новой версией схемы базы. Или наоборот, новая версия приложения могла работать со старой схемой базы.
То есть удаление таблички: сначала деплоите приложение, которое уже не работает с этой таблицей, потом удаляете таблицу
Новая табличка: сначала миграция, затем приложение
Новое поле в таблице с 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 запросом перенести куда надо с любыми манипуляциями по пути.

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

Работаем. Постоянно. У меня не установлено ни одного GUI к какой-либо базе

В psql вывод большого числа строк решается штатным \pset pager {on,off,always}, большое число столбцов обычно удобнее в развёрнутом виде (\x) смотреть.
Или взять less в качестве PAGER и получить скролл таблицы и горизонтальный и вертикальный:

export PAGER='/usr/bin/less -S'
psql

Для клиента mysql помню только развёрнутый вывод \G после запроса:

mysql> select * from users \G
*************************** 1. row ***************************
        id: 104
      name: NULL
    gender: 0
birth_date: 0
     phone: NULL
1 row in set (0.00 sec)

По клиенту к ораклу ничего не скажу, не видел.

Решил сделать upgrade своих серверов, а точнее поместить все на 1, планирую взять Supermicro 6025T и крутить на нем виртуалки с необходимыми ролями в Hyper-V.

Внимание вопрос: нафига вам СХД?
Тем более речь о 2U шасси уже на 8 hotswap дисков для всего лишь 10тб места - до 112ТБ сырой ёмкости для современных дисков.

Нет, не создаётся. На той таблице, на которую FK ссылается индекс уже должен быть создан уникальный, на той таблице которая ссылается наличие индекса никак не проверяется и даже не требуется. Надо только понимать, что FK - for each row триггеры и без индекса будет N seqscan таблицы.

Обычно индекс создаётся вручную. Иногда намеренно не создаётся.

Основная проблема - на десктопных i7 отсутствуют дополнительные линки QPI, необходимые для взаимодействия между процессорами.

Поэтому в двухсокетных материнках и не каждая пара Xeon работать будет, нужны как минимум именно те, у которых активны QPI линки. Например, пара каких-нибудь Xeon W3680 не заведётся потому же, почему и пара i7. Они искусственно разделены на разные рынки.
И наоборот, ради пиара была даже вполне десктопная материнка, но всё равно требующая xeon - EVGA Classified SR-2