Сформированы корректирующие обновления для всех поддерживаемых веток PostgreSQL: 13.4, 12.8, 11.13, 10.18 и 9.6.23. Обновления для ветки 9.6 будут формироваться до ноября 2021 года, 10 - до ноября 2022 года, 11 - до ноября 2023 года, 12 - до ноября 2024 года, 13 до ноября 2025 года...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55629
>специально оформленного запроса прочитать содержимое памятиага!
не буду оригинальным: следует переписать на Dlang!
Не будешь. Переписывальщик.Сейчас ещё укуренные подоспеют со своим растом, когда у самих дыра на дыре и дырой прикрывая.
- Переписать на раст! Переписать на раст! Легализовать раст во всех штатах!
На пэхэпэ переписать
Это просто показывает что даже такие боги программирования которые пишут PostgreSQL раз в год, но все равно не могут в память. Щито поделаешь...
Со скулите, где тестов больше кода, вышло забавнее.
Что такое скулите?
> Что такое скулите?я имел в виду скулите3
sqlite3
А точно боги его пишут? А то архитектурных дыр там пока хватает. Начиная от способа удаления записей с последующей очисткой, и заканчивая отсутствием direct io.
А как должен удалять записи версионник?
Не хранить версии прямо в таблице, например?
> Не хранить версии прямо в таблице, например?поясните свою мысль
>> Не хранить версии прямо в таблице, например?
> поясните свою мысльЕсли хранить старые версии строк (или то, что нужно для их восстановления) не вперемешку с таблицей, а, например, в отдельном тейблспейсе, принципиально отпадает необходимость в вакууме.
>>> Не хранить версии прямо в таблице, например?
>> поясните свою мысль
> Если хранить старые версии строк (или то, что нужно для их восстановления)
> не вперемешку с таблицей, а, например, в отдельном тейблспейсе, принципиально отпадает
> необходимость в вакууме.отлично а как мы узнаем какие из них старые?
я так понимаю, вы предлагаете подход, подобный используемому в innodb, нельзя сказать, что у него совершенно нет недостатков.
Честно говоря, не в курсе, как там в InnoDB. Мне нравится, как в Оракле: в табличный тейблспейс пишется только актуальная версия строки. При изменении она же и обновляется. Для каждого вектора изменений пишется запись отмены изменений (undo), которая циклично пишется в отдельный undo tablespace (или, в далёком прошлом, rollback segment). При необходимости достать старую версию строки, берём текущую и последовательно накатываем на неё undo до нужного состояния. И никакого мусора.
> Честно говоря, не в курсе, как там в InnoDB. Мне нравится, как
> в Оракле: в табличный тейблспейс пишется только актуальная версия строки. При
> изменении она же и обновляется. Для каждого вектора изменений пишется запись
> отмены изменений (undo), которая циклично пишется в отдельный undo tablespace (или,
> в далёком прошлом, rollback segment). При необходимости достать старую версию строки,
> берём текущую и последовательно накатываем на неё undo до нужного состояния.
> И никакого мусора.ну да, оно самое.
в постгресе называется zheap и вяло пилится уже несколько лет. ЕМНИП update быстрее, delete немного медленнее; в сумме быстрее, но не сказать, что разница критичная.
насколько я понимаю, в ближайшее время ожидать не стоит.
direct io не нужно
lol Почему же не нужен? Зачем двойное кеширование и кривая работа линухового кеша?
Для некоторых рабочих нагрузок DIRECT_IO может оказаться не оптимальным: https://www.percona.com/blog/2013/01/03/is-there-a-room-for-.../
> lol Почему же не нужен? Зачем двойное кеширование и кривая работа линухового кеша?Всё немножко наоборот. DIO - это костыль, необходимый в случаях, когда логика юзерспейса плохо стыкуется с логикой кэширования ФС.
У постгреса такой архитектурной проблемы нет.
Кеширование гарантирует сохранность данных? Зачем тогда большинство баз работает через DIO? Кеш никогда не является блокером? Может он не вымещается, по случайному скану?
> Кеширование гарантирует сохранность данных? Зачем тогда большинство баз работает через DIO?Очень хороший вопрос.
В некоторых СУБД (не будем показывать пальцем) все свежий изменения текущего состояния собраны в одном файле, и для фиксации изменений на диск достаточно одного вызова fsync().
В других СУБД (опять-таки, не будем показывать пальцем) отличия записанного состояния от текущего разбросаны по множеству файлов, причем некоторые из них могут быть очень большими. Тут уже, если хочется мало-мальски надёжно, без костылей direct io никак.
> А то архитектурных дыр там пока хватает. Начиная от способа удаления записей с последующей очисткой,Если вы про VACUUM FULL, то это вполне типичный вариант для больших объемов данных, когда после каждого чиха не начинается фоновое переписывание таблицы.
> и заканчивая отсутствием direct io.
Direct IO - затычка для ситуаций, когда кэширование создает проблемы с производительностью. А чтобы это произошло, нужно _очень_ извр^Wнетрадиционно использовать кэш. Монти, впрочем, смог.
Это просто показывает что даже такие боги программирования которые пишут PostgreSQL раз в год, но все равно не могут в памятьПотому му что есть околодебилы которые архитектора потерли и побежали вверх по донатам , это все последствия не внимательности что архитектор хоть и не кодер программист , но и не последний человек
Самая популярная РСУБД на данный момент, поэтому молодцы что багфиксят
long live, mongo
У растоманов печот что не на расте