там скорости передачи повыше, и могут в отличии от SATA достигать 2-3гигабит в секунду.
SATA II - это уже до 3 гбит/с на интерфейсе. SATA III - до 6гбит/с
M.2 - это до 4 линий PCI-E 3.0, чуть меньше 4 гигабайт в секунду предел, не гигабит.
Ну а дальше вопрос к контроллеру и типу нагрузки. Последовательная передача давно уже упирается в SATA интерфейс.
Повторюсь: обычно используются оба одновременно. pg_dumpall -g для глобальных данных кластера и отдельно pg_dump для сохранения снимков отдельных базы, которые надо бекапить. Раскатывается при необходимости соответственно в обратном порядке, сначала глобальные данные из pg_dumpall -g, затем из снимков pg_dump в нужные базы сами данные этих баз.
pg_dumpall в чистом виде использовать тоже можно. Но если вам понадобится восстановить отдельную табличку - это будет несколько неудобно.
Как уже упомянул - посмотрите patroni.
О pacemaker коллега отзывался как о довольно сложной штуке где легко ошибиться и надо много тестировать свои конфиги, про repmgr - как штука может и неплохая, но с довольно печальной документацией.
От вас зависит. Нужен вам балансировщик или нет, если нужен то что и как балансировать. Нужны вам 3 реплики или два кластера мастер+реплика - тоже мне неизвестно.
Пулер коннектов - обычно нужен. Типично pgbouncer в transaction mode локально на каждой машине с базой.
Если у вас не сохранён ВЕСЬ PGDATA, включая все файлы и всё по симлинкам - то база разрушена и нормально не стартует уже никогда. Ненормально тоже не стартует.
$PGDATA/base - это не рабочий каталог. Рабочий каталог - это $PGDATA целиком.
А так - ничего сказать нельзя, возможно ли достать хоть что-нибудь хоть в каком виде. Можно попробовать resetxlog дёрнуть или к pg_filedump и исходникам приставать.
index support is bound to operators in Postgres, not to functions.
По настройкам - надо понимать под какое окружение настраивать. CPU/RAM/диски, выделенная железка под базу или ещё всякое здесь же крутится, объёмы данных в гигабайтах.
Судя по использованию SIMILARITY - вы, вероятно, используете pg_trgm. Index support есть во-первых только с указанием gin_trgm_ops или gist_trgm_ops и во-вторых - для описанных операторов. Не для функций.
Смотрите попутно вот неплохой ответ: https://dba.stackexchange.com/a/103823
Запрос-то какой выполняется? А то окажется, что вопрос вообще к базе не относится, потому что ваш код вычитывает всю таблицу и считает её локально.
Параметры вы назвали странные. Судя по effective_cache_size + shared_buffers не похоже, что у вас есть пара сотен гигабайт RAM свободных. Для тяжёлого OLAP запроса в 1-5 потоков всего на сервер, где такой work_mem бывает нужен, соответственно опять же буфер слишком маленький.
Почему вы назвали wal_buffers важной настройкой - для меня загадка.
в postgresql вроде умеет как угодно с датами и их сравнением.
Мой ответ, кстати, для postgresql так же актуален. За одним нюансом - в postgresql можно сделать индекс по immutable функции - если дополнительный индекс обходится дешевле чем переписать запрос. Но условия вида "функция(поле_таблички) оператор" всё равно должны настораживать.
К слову, аналогично должны настораживать явные приведения типа. field::date = ? - индекс по field использоваться уже не может.
SATA II - это уже до 3 гбит/с на интерфейсе. SATA III - до 6гбит/с
M.2 - это до 4 линий PCI-E 3.0, чуть меньше 4 гигабайт в секунду предел, не гигабит.
Ну а дальше вопрос к контроллеру и типу нагрузки. Последовательная передача давно уже упирается в SATA интерфейс.