Comments 17
README так и не появился, судя по гитхабу?
Когда в следующий раз мне фанатик будет доказывать "мускул гавно", я его спрошу "а ты знаешь историю про 61 версию патча в постгресе?"
уже 65 версия 🙂 Я статью в мае писал, тогда последней была 61 версия. За новыми версиями можно следить в конце страницы https://www.postgresql.org/message-id/flat/CACG%3DezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe%3DpyyjVWA%40mail.gmail.com
Magic number в HeapPageSpecialData и magic numbers о которых волнуется AutomationLikeCrazy это совершенно разные magic numbers.
Могу сказать почему я, как первоначальный автор патча 64-битных идентификаторов транзакций, потерял к нему интерес.
1. Необходимость переодического freeze всё равно необходима исходя из структуры постгресового движка хранения. Как минимум, необходимо периодически "обрезать" SLRU, в особенности multixacts, который может неслабо распухать, в особенности после перевода на 64 бита.
2. Как было правильно написано в статье, xmin и xmax остались 32-битными, и из-за этого транзакции в рамказ страницы не могут отличаться больше чем 2^32, приходится иногда делать внутристраничный freeze и везде таскать с собой 64-битные базовые значения. Вроде бы всё это приемлемо, но создаёт некое ощущение костыльности от которого не получается избавиться.
3. Патч 64-битных идентификаторов транзакций задумывался до появления freeze map. После появления freeze map острота проблемы очень сильно спала.
В итоге патч вроде бы и полезен, но с одной стороны он не может решить проблему радикальным образом, а с другой – его очень сложно продвигать.
В целом же, моё видение того как нужно радикально решать проблемы движка PostgreSQL реализовались в виде моего проекта OrioleDB.
Спасибо за комментарий, позновательно и полезно! А что такое freeze map?
карта заморозки. Её встроили в карту видимости в версии 9.6
Всё больше начинает быть похожим, что MVCC стиля Postgres был ошибкой.
В варианте, когда строка заменяется на новую, а старая версия живёт в журнале до момента окончательной фиксации, можно делать хоть 256-битные счётчики, всё равно они много места не займут, а аналог vacuum выполнится просто дежурной чисткой журнала...
Или у стиля Postgres есть какие-то суперпреимущества, которые полезны в некоторых типовых сценариях?
в основном, данные вставляются, для вставок нет разницы. Сложность других реализаций примерно такая же - очень сложная в неожиданных местах. EnterpriseDB не смогли сделать расширение zheap. Возможно, расширению OrioleDB удалось учесть все детали. Пример сложности: в Oracle Database в буферном кэше один блок может иметь несколько версий на разное время (CR block). В PostgreSQL в буферном кэше блок может храниться только в одном буфере.
Суперпреимущества могут быть для большого числа запросов, которые начались незадолго до обновления или удаления строк. Обновления быстрее - в лучшем случае затрагивают один блок, а при использовании UNDO надо записывать старый образ в блок UNDO. Копирования строк в блоке для новой версии накладны, как и полные образы блоков.
Я пока не ставил на эту тему экспериментов, на на мой взгляд у PostgreSQL MVCC преимущества всё же есть. Основное преимущество – обработка старых снапшотов с вменяемой производительностью, особенно в запросах, которые обрабатывают много данных.
Например, у нас есть таблица, в которой за время существания снапшота каждая строка поменялась в среднем 3 раза, соответсвенно таблица распухла в 4 раза. Для того, чтобы прочитать её в соответствии со снапшотом, её нужно последовательно всю прочитать и выполнить для каждого тапла довольно простой MVCC-тест. И это одинаково и для старого стапшота и для свежего. В случае MVCC на базе undo, свежий снапшот просканирует только актуальные данные, а вот для старого снапшота мы начнём почти для каждой строки читать цепочку из в среднем 3-ёх undo-записей. И если эти undo-записи в силу своего объёма не будут закэшированы, то мы начнём на каждую undo-запись тратить реальные IOPS'ы, что выглядит катастрофой.
То есть в случае существования старых снапшотов, PostgreSQL MVCC обрабатывает сканирование и по старому и по свежему снапшоту одинаково "посредственно". В случае же undo свежий снапшот будет работать хорошо, а со старым произойдёт катастрофа. Но суперпреимуществом именно для типовый сценариев я бы это не назвал. Цена (распухание + замедление свежих снапшотов) выглядит слишком высокой.
Повторюсь ещё раз, что это теоретические соображения, которые я пока не проверял.
Ну, специфический сценарий всегда можно подобрать.
Я просто к тому, что наблюдается проблема с этим счётчиком и отложенной сборкой при vacuum у всех (ну, 95+% или даже 99+%), а выгоду получают считанные единицы. Хорошо, пусть новые строки заводятся в той же таблице. Почему не сделать установку флага "свободен" на старых версиях строк (или удалённых строках) как часть процедуры фиксации коммита, без откладывания? Какая такая особенная ценность организации отдельного регулярного GC для этих строк?
xmin/xmax необходимы для того, чтобы все обладатели всех различных снапшотов могли понять видят они данную версию или нет. Проход VACUUM в дальнейшем необходим для того чтобы найти таплы, которые уже никому не будут видны, удалить на них ссылки их индексов, а затем и сами таплы.
Это точно так же, как с управлением памятью по счётчику ссылок или GC по недостижимости. Вы, по сути, рекламируете GC по недостижимости, говоря, что он что-то умеет. Но практика альтернативных подходов во всех прочих БД показывает, что по счётчику ссылок работает, с теми же умениями. Так чем здешний GC по недостижимости лучше? Лучше ли он в статистическом большинстве сценариев?
Насчёт «почему есть только в коммерческих форках» не согласны, мы активно продвигаем его в ванильную PostgreSQL. И даже написали про это статью:
https://habr.com/ru/companies/postgrespro/articles/864142/
64-битный счётчик транзакций в PostgreSQL