Postgres Professional corporate blog
PostgreSQL
SQL
Comments 10
+1
Егор, спасибо за статью. Особенно интересна рекомендация про fulfill фактор как возможность оптимизации производительности. Надеюсь, выпадет случай применить ее на практике.

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

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


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

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

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

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

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

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


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

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


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

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

Что будет происходить? Вероятно, ситуация решается физическими блокировками страниц?
+1
Да, чтобы что-то сделать со страницей, очистка должна ее заблокировать в буферном кеше. Поэтому они друг другу не помешают.
Only those users with full accounts are able to leave comments. , please.