Вишу с утра :(
Вчера пришла retention policy, вычистила 30% записей в таблицах, с утра узрел падение reltuples, стало обидно за просто так занятое место на диске)

конечно

а в pgsql есть аналог mysql'ного select for update? чтения в repeatable read оставляют какие-то следы?

как правильнее всего организовать обнвление связанных данных чтобы избежать "ножниц"?... В каком режиме выполнять транзакцию?

Я слышал постгрес сделлал SSI, SSI работает на всех уровнях изоляции или только в serializable?

есть и несколько режимов, берёт строчные локи (мофицирует xmax в туплах), как и при update

речь идёт об избежании деадлока при обновлении связанных данных?

да, SSI включается только в serializable

да

(спасибо за ответы)

от режима не зависит, просто обновление строк должно быть в одном порядке. Потенциально, даже update пересекаемых батчей строк может приводить в деадлоку, если один update будет проходить через IndexScan (случайный порядок обновления в хипе), а другой - через BitmapIndexScan (последовательный порядок в хипе)

На postgresql.org публикован перевод Кодекса поведения для участников сообщества PostgreSQL. Благодарим команду редакторов - Александра Лахина, Анастасию Лубенникову, Валерию Каплан и Виктора Егорова. Дополнительную редактуру сделала автор перевода (я). Текст был серьёзно переработан с учётом всех комментариев, устранена речевая избыточность, ликвидированы расхождения в терминологии с ранее переводившимся пресс-релизами проекта PostgreSQL. Данный документ может быть вам полезен, если вы организуете мероприятия и любые другие активности в сообществе. Например, наша команда брала его за основу для аналогичного документа PGConf.Online. Всем добра! https://www.postgresql.org/about/policies/coc/ru/

Скоркй всего речь шла про аномалию write skew, а не про deadlocks.
Ну да, она "лечится" с помошью serializable уровнем изоляции (SSI).

Всем привет, знатоки подскажите пожл, к примеру ситуация такая: запущены 3 потока(пусть это будут горутины на go), которые выполняют вставку(30к строк за раз) данных в одну таблицу, так вот, вставка будет параллельная или последовательная? То есть к примеру все потоки одновременно отправили данные на вставку(одна порция 30к строк ~ 10секунд ), в итоге общее время вставки с точки зрения pg, будет ~30 сек или ~10 сек?

из индексов только pk

А pk какой? Который автоинкремент?
Я бы вам посоветовал тест провести)

а код таблицы можно ?
ибо pk может разным
это может быть просто ограничение уникальности
а может быть вычисляемым автоинкриментом

да, но туда тупо вписывается ид взятый из другой таблицы))

ограничение по pk:
id int8 NOT NULL GENERATED ALWAYS AS IDENTITY,

я вот как раз и тестирую и пока не оч пойму)