Реклама
Комментарии 10
Егор, спасибо за статью. Особенно интересна рекомендация про fulfill фактор как возможность оптимизации производительности. Надеюсь, выпадет случай применить ее на практике.

Так как Вам удобнее отвечать на вопросы в отдельных комментариях — напишу их также отдельно.

Внутристраничная очистка убирает версии строк, не видимые ни в одном снимке (находящиеся за «горизонтом событий» базы данных, об этом мы говорили в прошлый раз), но работает строго в пределах одной табличной страницы.


Пусть изменилось поле text, которое настолько велико, что хранится в TOAST. Пусть его изменили несколько раз. Началась внутристраничная очистка. Полагаю, что для TOAST она не работает? Потому что TOAST — это размещение данных на нескольких страницах.

применяется ли MVCC к TOAST? Вероятно, это будет раскрыто в последующих статьях и вопрос преждевременный.
Владимир, спасибо. Отвечать более или менее все равно как, а читать потом легче, когда ответы стоят рядом с вопросами, как мне кажется.

Потому что TOAST — это размещение данных на нескольких страницах.

Это не совсем так. TOAST — это размещение данных, которые не помещаются на одной странице, но как они размещаются? Они нарезаются на фрагменты, каждый из которых — помещается. Так что TOAST-таблица практически ничем не отличается от обычной и к ней все сказанное тоже применимо, включая и MVCC.

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

TOAST-таблица используется только при обращении к «длинному» значению. Кроме того, для toast-таблицы поддерживается своя версионность: если обновление данных не затрагивает «длинное» значение, новая версия строки будет ссылаться на то же самое значение в TOAST-таблице — это экономит место.


А если происходит обратная ситуация — меняется только «длинное значение»? Что происходит? Создается новая версия строки, по сути, копия уже существующей с той лишь разницей, что ссылка будет указывать на новую версию TOAST-таблицы?

Если так, то понятно, как будет работать HOT в данном случае. Если нет — поясните, пожалуйста, механизм с TOAST.
Все неактуальные версии строк (0,1), (0,2) и (0,3) очищены; после этого на освободившееся место добавлена новая версия строки (0,5).


Ради интереса я выполнил UPDATE в транзакции и потом откатил транзакцию. Строки все равно остались очищенными. То есть внутристраничная очистка от транзакции, видимо, никак не зависит. Как и проставление битов статусов транзакций. То есть, такие операции нетранзакционны, видимо, в силу того, что такая транзакционность никогда не требуется.
Да, очистка от границ транзакций напрямую не зависит. А зависит от горизонта событий.
(Другое дело, что пока транзакция работает, горизонт не даст удалить версии строк, которые в этой транзакции меняются.)
Внутристраничная очистка и VACUUM

Получается, что последующая процесс AUTO VACUUM почистит индексные страницы и уберет unused указатели? А также удалит цепочку.
Цепочку не надо удалять, она хорошая. А в остальном — да, именно так. Об этом в следующий раз (:
Вероятно, следующий вопрос слишком низкоуровневый — а как фоновый AUTO VACUUM и внутристраничная очистка «делят между собой» процесс очистки? Пусть автовакуум хочет удалить цепочку, а начавшаяся внутристраничная очистка хочет цепочку продолжить.

Что будет происходить? Вероятно, ситуация решается физическими блокировками страниц?
Да, чтобы что-то сделать со страницей, очистка должна ее заблокировать в буферном кеше. Поэтому они друг другу не помешают.
Только полноправные пользователи могут оставлять комментарии. , пожалуйста.