Руководство по созданию эффективных запросов

м
ассовые
 
оБновления
 
и
 
частые
 
оБновления
Как упоминалось ранее, PostgreSQL никогда не уничтожает данные сразу. Ко-
манда 
DELETE
помечает удаленные строки как удаленные, а команда 
UPDATE
вставляет новую версию строки и помечает предыдущую версию как устарев-
шую. Когда эти строки больше не нужны для активных транзакций, они стано-
вятся «мертвыми». Наличие «мертвых» строк уменьшает количество активных 
строк в блоке и, таким образом, замедляет последующие сканирования таблиц.
Пространство, занятое «мертвыми» строками (то есть удаленными версия-
ми строк), остается неиспользованным до тех пор, пока не будет возвращено 
операцией очистки 
VACUUM
. В большинстве случаев, даже при относительно 
высокой частоте обновлений, обычная очистка, инициированная демоном 
автоматической очистки, быстро устраняет мертвые версии строк, так что 
они не вызывают каких-либо значительных задержек.
Однако если выполняется массовое обновление или удаление (то есть лю-
бая операция, влияющая на большую часть таблицы), запрос к этой таблице 

---

Ссылочная целостность и триггеры 

163
может значительно замедлиться, потому что карта видимости заставит пере-
проверять видимость, обращаясь к блокам таблицы. Также, как упоминалось 
ранее, количество активных версий на странице уменьшится. Это приведет 
к тому, что каждый запрос будет считывать в память большее количество 
блоков, а это в конечном итоге может привести к тому, что база данных нач-
нет выполнять собственные внутренние операции подкачки.
В таком случае требуется агрессивная настройка автоматической очистки 
или ручное выполнение операций 
VACUUM
ANALYZE
.
Выполнение очистки может вызвать существенное увеличение ввода-вы-
вода, что приводит к ухудшению производительности других активных се-
ансов. Очистку можно настроить так, чтобы распределить ее воздействие во 
времени и таким образом уменьшить количество резких всплесков ввода-
вывода. Однако в результате очистка будет занимать больше времени.
Теперь рассмотрим другой случай: таблица часто обновляется, хотя каждое 
из этих обновлений влияет на одну или очень небольшое количество строк.
Как обсуждалось ранее, любое обновление строки создает новую копию. 
Однако если новая версия хранится в том же блоке и значение индексиро-
ванного столбца не изменяется, тогда нет необходимости обновлять индекс, 
и PostgreSQL не будет его трогать.
Чтобы описанная функция работала, блоки должны содержать достаточное 
количество свободного места.
Процент свободного пространства в табличных блоках можно задать с по-
мощью параметра хранения 
fillfactor
в предложении 
WITH
команды 
CREATE
TABLE
. По умолчанию значение этого параметра равно 100: PostgreSQL стара-
ется уместить в блоках как можно больше строк и минимизировать свобод-
ное место. Таким образом, обычно свободное место может появиться только 
после обновлений или удалений с последующей очисткой.
Чтобы уменьшить накладные расходы на обновление индексов, можно ука-
зать меньшие значения 
fillfactor
. PostgreSQL допускает значения вплоть до 
10, оставляя 90 % блочного пространства для обновленных версий строк. Ко-
нечно, маленькие значения параметра 
fillfactor
приводят к увеличению ко-
личества блоков, необходимых для хранения данных, и, следовательно, к уве-
личению количества чтений, необходимых для сканирования таблицы. Это 
значительно замедляет длинные запросы, но может быть менее заметным для 
коротких запросов, особенно если из блока выбирается только одна строка.