Melkij

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

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

Никаких. Совсем никаких. Это штатный вариант работы, есть даже штатная настройка cluster_name, которая будет выводиться в списке процессов для лёгкости идентификации, на какой именно кластер вы смотрите. Для debian/ubuntu - управляется вовсе стандартными штатными утилитами pg_ctlcluster.

Нужны разные datadir и не пересекающиеся сетевые настройки

Нужен опорный список значений и not exists подзапрос. Опорный список можно сделать через generate_series функцию

select n from generate_series(1,11) as n
where not exists (select from tablename where id = n)

Практически буквально так и пишется:

SELECT * from cc_files WHERE lptime < now() - interval '1 hour'

2 млн записей - это такие копейки.
Что-то делают обычно когда проект не влезает в описание "сейчас никаких проблем".

Что основное можно сделать:
покрутить настройки checkpointer (чтобы checkpoint срабатывал реже - резко меньше random i/o, но при крахе база может дольше стартовать), autovacuum (опустить оба scale_factor куда-нибудь в 0.05 - чтобы автовакуум запускался чаще, но делал меньше работы, плюс уменьшить autovacuum_vacuum_cost_delay - это зависит от дисков)
shared_buffers где-то в 25% от объёма RAM
включить pg_stat_statements и поглядывать топ запросов оттуда