Интересное чтиво:https://habrahabr.ru/company/southbridge/blog/322624/
Из эпичного:
логически небольшое обновление (скажем, запись нескольких байт) становится гораздо более серьезной и ресурсоемкой операцией на физическом уровне.
После того как мы обновили год рождения al-Khwārizmī, не изменились ни первичный ключ записи, ни значения имени и фамилии. И все же индексы приходится обновлять, поскольку в базе данных появился новый кортеж. Для таблиц с большим количеством вторичных индексов эти дополнительные шаги могут приводить к значительным накладным расходам на запись. Например, для таблицы с десятком индексов обновление поля, покрытого лишь одним индексом, должно быть распространено на остальные девять, поскольку необходимо прописать в них ctid новой строки.
Проблема с усилением записи затрагивает и репликацию, которая выполняется на уровне представления данных на диске. Вместо передачи небольшой логической записи, такой как, например, «Изменить год рождения для ctid D, установив его в 770», СУБД должна переслать все элементы WAL, касающиеся четырех вышеупомянутых операций, сопровождающих запись. Таким образом, проблема усиления записи переходит в проблему усиления репликации, и поток репликационных данных Postgres очень быстро становится настолько значительным, что может занять большую часть доступной пропускной способности сети.
Во время стандартной операции по увеличению емкости базы данных, при которой использовался механизм повышения роли реплики, мы столкнулись с ошибкой в Postgres 9.2. Реплики некорректно обрабатывали переключение шкалы времени (timeline switch), в результате чего некоторые из них неверно применяли обновления WAL. Из-за этой ошибки некоторые записи, которые должны были быть деактивированы механизмом версионирования, не получили соответствующую пометку, то есть остались активны. поскольку ошибка проявлялась на всех серверах, каждый из них портил разные строки, то есть на одной реплике строка X могла быть повреждена, а Y нетронута, но на другой реплике строка X могла быть в порядке, а Y — повреждена. На самом деле мы точно не знали, на скольких репликах были поврежденные данные, а также проявлялась ли эта проблема на мастере.
