Может у кого-то есть опыт тюнинга репликации.
Ситуация такая. Есть мастер, есть реплика.
PG10
На на мастере запустили довольно тяжелый запрос
который заполняет таблицу данными из других таблиц
размер таблицы около 2GB после заполнения.
Во время заполнения через некоторое время отвалилась реплика.
Предположил что реплике не хватило количества wal файлов
как я понял за это отвечает параметр конфигурации
wal_keep_segments
и сейчас он выставлен в 128
и всё работало отлично
видимо первый раз такая большая таблица попалась

вопрос - правильно ли я копаю?
и как правильно рассчитывать этот параметр?
и какие побочки могут быть если его увеличить?

у вас WAL файлы быстро “ротируются”. предположим, что все 2Gb попали в WAL (это 128 сегментов).
чекпойнты из коробки срабатывают при записи 1GB (64 сегмента), значит у вас было 2 чекпойнта, значит WAL-ы успели отротироваться на мастере.
если всё это было быстрее, чем эти ваши 2GB могли пролезть по сети — мы пришли к тому, что на мастере мы слишком быстро промотали WAL.

я бы рекомендовал посмотреть на настройки контрольных точек в первую очередь, при адекватных настройках мастер не будет так быстро ротировать сегменты.
я обычно ставлю таймаут в 1 час и ставлю max_wal_size=16G

ну и да, wal_keep_segments тоже помогут. 1024 = +16GB на диске

> Предположил что реплике не хватило количества wal файлов

Да, скорее всего.

>  за это отвечает параметр конфигурации wal_keep_segments

В том числе, да.

> и как правильно рассчитывать этот параметр?

А почему бы не посмотреть на слоты репликации вместо этого параметра?

Лариса Фокина: user has been CAS banned

Подскажите пожалуйста, в psql 1 юзер может делать 1 запрос?
В рамках 1го коннекта или вообще?

@molescenko странный вопрос 😉 сколько угодно запросов

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

согласен да, запрос сформулирован очень невнятно )))

Теоретический вопрос по перформансу (негде проверять сейчас, да и скорее просто интересно чем критично)😄

Есть скажем 1млн записей id,name,some_number_val

содержимое поля “name” всегда содержит некоторый префикс. K примеру: “B: Nike”; “C: Running Shoes”; “G: Shoes”

Учитывая что по name есть индекс: Что будет быстрее - запросы с фильтром: where name like “B:%”  или запрос по полю some_type = “B” (ситуация в которой префикс продублирован в отдельное поле)

при вынесении в отдельное поле cardinality будет никакой - 3 значения

А я бы настроил archive_command на мастере и restore_command на реплике. Слоты репликации имеют очень неприятное свойство забивать $PG_DATA, когда реплика начинает отставать, а вы с этим ничего поделать не можете. Было и такое - диски на реплике просели на запись, и оппа! 95% PG_DATA занято. Аврал, полкомпании рвут все разные части тел, ну и вот это вот всё...

ради справедливости надо отметить, что в 13 версии запилили параметр max_slot_wal_keep_size, который как раз и призван решать эту проблему

Если индекс построен правильно с использованием магии "varchar_pattern_ops" и работает нормально, то на миллионе записей разница будет гомеопатическая.

Интересно, а если поле type неселективное (например, там 5 значений на 10000 строк), а по name не построена гистограмма. Он ведь теоретически может при отборе по name пойти по индексу вместо того, чтобы всю таблицу смотреть, и это в данном случае может быть неоптимальным вариантом. Или я не прав?

Теоретически оно и сегфолтнуться может.
Но я вопроса не понял.

Ребят, мне нужно отсортировать таблицу по году, и обнулить sequence, чтоб отсчёт шел от 1, как мне это сделать?

В инете гуглю, но чёт все с ошибками показывает

Не понятно какая связь м/у сортировкой и сбросом сиквенса

Ну у меня есть данные, и они не по порядку. Т.е например 2001 год стоит под id 5, когда должен быть под id 1.
Я хочу остортировать по году, и перезаписать новый sequence. Это возможно ?

Напрямую наверное нет, id скорее всего uniq. Ч/з промежуточное значение.