Comments 12
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. И даже написали про это статью:
https://habr.com/ru/companies/postgrespro/articles/864142/
64-битный счётчик транзакций в PostgreSQL