Нет. И как Вам удалось прийти к такому предположению, я даже не понял. ;)

нашел "распухший" индекс, пошел в статистику.
посчитал
(((idx_tup_read::float4 - idx_tup_fetch::float4)/idx_tup_read)*100)
увидел 90%

1. Что такое "распухший", конкретно (и зачем его перестраивать)?
2. Для этого индекса что-то с чем-то совпало, например. ;)
Вы документацию читали по этим полям (Вы же не её цитируете, а что-то "левое" (и с ошибками, с виду))?
https://www.postgresql.org/docs/current/monitoring-stats.html#PG-STAT-ALL-INDEXES-VIEW

1. он был в несколько раз больше по размеру, чем данных в таблице, и после реиндекса уменьшился примерно в 10 раз.
2. Доку я читал, но... увидев "The latter will be less if any dead or not-yet-committed rows are fetched using the index, or if any heap fetches are avoided by means of an index-only scan.", не очень понял 😞, начал гуглить пояснения.
Наткнулся на книгу "PostgreSQL 10 High Performance: Expert techniques for query optimization ..." в которой был вышезаскриненный абзац.
Ну и решил уточнить, правильно ли я понял то, что там написано)
Как оказалось - нет.

в том и дело, что гуглится противоречивая информация по этому вопросу
русскоязычная дока от ПГПро даёт одно представление, янглоязычная от ПГ другое)

Может, настройкой autovacuum стоит заняться, в таком случае (т.е. вообще посмотреть, что там с bloat в базе)?
Хотя могут быть нагрузки, когда он мало поможет (но редко, по идее) — можно посмотреть, как там с ней работают...

По умолчанию "источник истины" — это официальная документация PostgreSQL. ;)
Всё остальное может содержать [дополнительные] ошибки.

но я правильно понял, что
в tup_read содержится счетчик tuple, которые были прочитаны по скану индекса + bitmap scan(когда нельзя определить, с помощью какого именно индекса была получена информация),
а в tup_fetch - только кол-во полученных "живых" строк. И напрямую сравнивать эти 2 значения(как предлагают некоторые ресурсы) - нельзя?

В документации же ясно написано, как правильно, нет?

> когда нельзя определить, с помощью какого именно индекса была получена информация

Эээ... откуда Вы это взяли (можно/нельзя тут не имеет значения — если читался tuple из индекса, то idx_tup_read++).

> а в tup_fetch - только кол-во полученных "живых" строк.

Да, только непосредственно "через" индекс: "Number of live table rows fetched by simple index scans using this index".

> И напрямую сравнивать эти 2 значения

Да попробуйте Вы взять какую-то простую тестовую таблицу, и посмотрите, как на статистике отражаются разные виды доступа — будет понятно, я думаю.

спасибо
попробую

Ребят, добрый вечер! СУБД постгря, нужно ночью сменить машину. Подскажите, как перенести базу данных с одной машины на другую?

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

А если решать эту задачу без простоя? (Мне не обязательно без простоя, но очень интересно)

Второй вариант через синхронную репликацию

1)base_baсkup на вторую машину, поднятие как второго сервера как hotstandby, переключение
2) Логическая репликация

версия ПГ будет одна и та же?

Логическая репликация - это для тех кто любит погорячее

можно еще pacemaker заюзать)

Да

если есть возможность остановить первый сервер, то после остановки скопировать data/ на второй сервер и там запустить.

ааа). сорри, я не заметил что простой недопустим((