Melkij

Передайте pg_class.oid и всё.

pg_size_pretty(pg_table_size(с.oid)) AS size,
pg_size_pretty(pg_indexes_size(с.oid)) AS idxsize,
pg_size_pretty(pg_total_relation_size(с.oid)) as "total"

Если загляните в определение pg_tables - то увидите, что это view от pg_class с фильтром relkind = 'r'. То есть объединение с pg_tables довольно лишнее.

Настроек у него никаких, поэтому достаточно проверить, что он загружен, т.е. упомянут в
show shared_preload_libraries;

copy можно указать поля таблицы для заполнения, то есть в таблице может быть полей больше, чем в источнике данных. Такие дополнительные поля должны иметь значение по-умолчанию или быть null

COPY test (field1, field2, ...) FROM 'test.csv' DELIMETR ',' CSV;

Синтаксиса для пропуска полей не предусмотрено.

pga_hba.conf можете редактировать как и чем угодно, это не имеет отношения к базе (ну разве вы только руками переопределили hba_file).
А файл правил авторизации pg_hba.conf необходимо редактировать текстовым редактором, желательно каким-то адекватным который не будет заниматься самодеятельностью с правами, именами, владельцами и содержимым файла. После внесения правок в pg_hba необходимо скомандовать reload базе.
select pg_reload_conf();
Запросом от суперпользователя предпочтительнее, т.к. не зависит от платформы.

от клиента запрашивается пароль дважды хешированный алгоритмом MD5

Единожды хэшированный согласно способу аутентификации md5 протокола libpq.

Ну и конечно надо понимать, что меняется и где именно. pg_hba обрабатывается по порядке сверху вниз и правило вполне можно указать даже банально не там где нужно.
Плюс при reload смотрите в лог, сообщения об ошибке формата там будут.

Вы в after insert триггере на табличке со странным названием lechenie выполняете безусловный insert в эту же самую таблицу. Вопрос к вам: почему вы в результате ожидаете что-то кроме бесконечной рекурсии?

В postgresql все текстовые типы следуют кодировке базы. case insensitive utf8 в pg не предусмотрено.
Поэтому если у вас база в utf8 - то "STEM" varchar(50) not null
Если база не в utf8 - не надо так делать.

Всё очевидно:
суперпользователь базы - лицо доверенное и база доверяет этому пользователю. И суперпользователь множеством хитрых и не очень способов способен сделать с сервером на котором запущена база всё на что хватит прав у пользователя, от которого запущен postgres.
Например, запустить любую произвольную команду даже простой и очевидной командой copy, не говоря уже о каких-то извращениях.

Конкретная атака по-видимому уже разобрана и описана вот тут: https://habrahabr.ru/post/351452/

Никогда не используйте trust, уж тем более в мир. В нормальном состоянии база вообще не должна быть открыта в мир.

2. Нужно ли включать order by в таких огромных таблицах?

Не зависит от размера базы.
Или у вас есть order by и поведение ожидаемое или у вас нет order by и СУБД имеет полное право на каждый запрос выдавать любые подходящие под фильтр данные в любом порядке.
Запрос выдающий неправильные данные обычно никому не нужен, даже если он и быстрый.

offset для пагинации вообще вещь неуклюжая. https://use-the-index-luke.com/no-offset
Быстрая пагинация - это передача уникального идентификатора, последнего на просматриваемой странице. Т.е. запрос на выборку следующих 100 записей начиная после такого-то id.
Бонусом консистентное поведение, если, например, что-то из строк предыдущей страницы удалили. Оффсет тупо потеряет строку из выборки и пользователь может не найти то что искал.

3. Ну типа берем сначала вытаскиваем данные с одной таблицы, потом по результату смотрим id, по нему вытаскиваем данные связанные со второй таблицы, затем смотрим новый результат и так же вытаскиваем с третьей. Получается в бд не будет строится огромная временная таблица из трех больших таблиц.

Вы изобрели то что делает джойн. База в общем случае его сделает лучше.
Будет ли огромная временная таблица - смотрите план.

pg_repack - это community extension, форк более раннего pg_reorg. И не отрицая вклад участников pgpro в разработку postgresql в целом - я не вижу их среди контрибьютеров pg_repack.

Мы активно используем обе. Основные моменты касательно pg_repack vs pgcompacttable в общем-то именно я и изложил в README компактора. Если говорить на русском:
- pg_repack делает копию таблицы, т.е. требуется двукратный запас диска. Компактор работает в рамках одной таблицы и требует место только под копию наиболее толстого индекса и то, толстые индексы обрабатываются самыми последними. Т.е. расчёт на работу когда места уже мало.
- компактор намеренно выполняется медленно чтобы не задевать работающий проект
- компактор не может обрабатывать toast таблицы. Репак - может.
- pg_repack характеризуется очень заметными пиками io и wal. Вся таблица едет одной транзакцией и это никак не регулируется. Поэтому может аффектить прод на неважных дисках и в том числе оторвать реплики при недостатке сетевой полосы.
- pg_repack умеет перемещать между tablespace и может делать команду cluster

(или лучше подстроить автовакум)?

Конечно необходимо настроить автовакуум и не мешать ему работать - т.е. исключить долгие транзакции. Но всё равно бывают хитрые моменты, когда репак или компактор бывают нужны.