решение запускать вакуум или нет, расчитывается по формуле
n_dead_tup >= ((reltuples * autovacuum_vacuum_scale_factor) + autovacuum_vacuum_threshold)
у вас, n_dead_tup = 149371, reltuples возьмите из pg_class, scale_factor и threshold из конфига и посчитайте, если полученная цифра меньше n_dead_tup то постгрес считает, что вакуум не нужен.
Чтобы вакуум запустился сам, скорей всего надо подкрутить scale factor (вероятно он у вас дефолтный 0.2)

у меня сильное подозрение что все эти индексы - это индексы первичных ключей. и удалять их наверное не надо

А может быть такое что отметили как первичный ключ плюс еще как индекс?

Огромное вам спасибо👍

При добавлении первичного ключа - индекс B-tree автоматически создается

не стоит удалять индексы с суффиксом _pkey, 99% что это первичные ключи.

всем огромное спасибо, хороших выходных всем!

select indexrelname from  pg_stat_user_indexes where idx_scan=0;  — этим запросом вывел список и решил удалить все индексы без суффикса _pkey, правильно ли я делаю?

посмотрите когда сбрасывалась статистика для вашей БД,
select datname,now()-stats_reset from pg_stat_database where datname = 'DATNAME'; - DATNAME замените на свою БД, если стата сбрасывалась 2 и более месяцев, то да, можно рассмотреть удаление индексов - но будьте внимательны, смотрите чтобы под удаление не попали UNIQUE индексы (у них может не быть показательных префиксов)

Аа все ок, очень тонкие моменты раскрыли для меня, счастья вам в семье!

взаимно:)

Коллеги, а есть ли штатная возможность добавить префиксы/постфиксы ко всем именам колонок (не указывая все их по отдельности) при SELECT?
Что-то типа SELECT [prefix]* from table

нет

Виктор, благодарю за оперативный ответ :)

SQL декларативный, * — единственное, что есть. если несколько таблиц связываются, можно выбрать колонки только одной через tab.*
но префиксы колонок — никак, только через динамическое построение запросов любым удобным способом.

кстати, наличие в названиях колонок одинаковых префиксов может говорить о не очень удачно выбранной схемы именования. а может и не говорить ¯\_(ツ)_/¯

Касательно второго абзаца — это временные таблицы во время некоторых аналитических изысканий, поэтому так и получилось :)
Ещё раз спасибо

добрый день

подскажите в чём может быть проблема:
2021-03-26 20:18:30.749 MSK 14477 @ from  [vxid: txid:0] [] DETAIL:  The failed archive command was: /usr/bin/pgbackrest --stanza=pclpgdb02 archive-push pg_wal/00000004000000FE0000008A
2021-03-26 20:18:31.761 P00   INFO: archive-push command begin 2.32: [pg_wal/00000004000000FE0000008A] --compress-level=3 --exec-id=14489-bff095c4 --log-level-console=info --log-level-file=debug --pg1-path=/var/lib/pgsql/12/data --process-max=4 --repo1-host=tlpgbackup01 --stanza=pclpgdb02
ERROR: [050]: raised from remote-0 protocol on 'tlpgbackup01': unable to acquire lock on file '/tmp/pgbackrest/pclpgdb02-archive.lock': Resource temporarily unavailable
      HINT: is another pgBackRest process running?
2021-03-26 20:18:31.907 P00   INFO: archive-push command end: aborted with exception [050]
2021-03-26 20:18:31.908 MSK 14477 @ from  [vxid: txid:0] [] LOG:  archive command failed with exit code 50
2021-03-26 20:18:31.908 MSK 14477 @ from  [vxid: txid:0] [] DETAIL:  The failed archive command was: /usr/bin/pgbackrest --stanza=pclpgdb02 archive-push pg_wal/00000004000000FE0000008A
2021-03-26 20:18:31.908 MSK 14477 @ from  [vxid: txid:0] [] WARNING:  archiving write-ahead log file "00000004000000FE0000008A" failed too many times, will try again later

процессе архивации получил ошибку на сегменте wal

база постоянно переходит в режим восстановления