Melkij

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

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

с помощью утилиты 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 расширения.

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

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

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

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

Прежде всего проверьте версию СУБД. json_array_elements_text была добавлена в релизе 9.4.

Как я понял для ID лучше выбирать int, а не smallint.

Тип необходимо выбирать соответствующий данным.
Например, для идентификатора страны int будет явно избыточен. А где-то и int мало и нужен bigint

2. Для названия акции есть тип character varying(n), varchar(n) Нужно ли задавать его длину? Или можно оставить поле пустым?

Это вопрос к вам как автору схемы базы.

3. Как влияет задание длины поля на экономию места в базе?

Никак. Это просто дополнительное ограничение данных.
varchar и text - типы с переменным размером, занимают столько места, сколько данных записано.

Например сейчас все названия акций не более 10 букв, а что будет, если в будущем появится название из 30 букв? Придется изменять длину строки? Можно ли так делать, когда база уже частично заполнена?

Увеличивать размерность возможно и это быстрая операция.

4. Для чего ставить поле -Not null?

Дополнительное ограничение на данные, запрещающее ставить специальное значение NULL, то есть "нет значения". Использовать или не использовать NULL - решение автора схемы базы.
Если вы попытаетесь записать NULL в поле отмеченное not null - будет ошибка и ничего записано не будет.

Ваше приложение ещё не поддерживает вышедший в четверг postgresql 11. Возможно обновление уже выпущено, я так догадываюсь версия 2018.1 была довольно давно.

proisagg и proiswindow были удалены из системного каталога pg_proc ещё в марте до feature freeze и эти изменения вошли в postgresql 11.

rpm-based (redhat, centos) и deb-based (debian, ubuntu) ставят postgresql разным образом. Поэтому детали различаются.

PGDATA вида /var/lib/pgsql/9.6/data/ характерен для centos. Конфиг базы при этом лежит здесь же.
ubuntu кластер по умолчанию кладут в /var/lib/postgresql/9.6/main/
Логи в ubuntu по умолчанию будут писаться в /var/log/postgresql/postgresql-9.6-main.log , а конфиг - в /etc/postgresql/9.6/main/postgresql.conf

В общем-то, вопроса тут два:
найти куда пишутся логи базы либо изменить настройки, чтобы логи писались туда куда вы хотите. Это никак не связано с включением логирования запросов, это где логи в целом. Если у вас причина менять настройки места логирования - то вы уже должны представлять зачем.
включить логированиие запросов: настройка log_min_duration_statement позволяющий логировать запросы дольше указанного времени (0 - все запросы) или log_statement, логирующая всё указанного типа (например, все DDL)

При том практика centos писать логи в каталог базы в некотором отношении порочна: эти логи будут попадать в pg_basebackup, где им делать в общем-то совершенно нечего и незачем.

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

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