История изменений

Есть возражения. Ты можешь привести сценарий, где нужно будет читать много старых данных? Смысла в этом мало потому, что менять-то их нельзя - они старые, база уже уехала вперед.

Чуть менее чем любая «долгая» читающая транзакция должна читать «старые» данные, соответствующие своему MVCC-снимку. Если на фоне такой транзакции происходит много апдейтов, то начинаются проблемы. Только стоит учитывать, что понятие «долгая» тут может быть сильно растяжимым. Для простоты можно считать, это это некий fullscan терабайтной таблицы при построении мега-отчета на некий момент времени.

Не просто так Interbase, Oracle, MS SQL выбрали именно модель с логом возврата - два последних в итоге стали лидерами рынка, потому что двухкратный рост производительности записи на дороге не валяется.

Ну лидерами рынка они стали не поэтому, и «не просто так» в PostgreSQL выбрали COW. Двукратной разницы в производительности нет. Точнее говоря, его нет в среднем, а в каких-то отдельных сценариях каждый из вариантов может быть быстрее (пожалуй и более чем в два раза).

«Считать содержимое записи; записать измененную копию в новое месте; считать все индекса для этой записи; записать копию индексов с измененным указателем на новую запись» против «Считать запись; записать в нее новое значение; записать разницу в лог отмены» Может быть, без индексов постгрес будет работать с равной скоростью. Только какой же постгрес работает без индексов? Там как минимум по основному ключу всегда есть индекс.

Ну вот не совсем так, мягко говоря. Запись реализуется по-странично, поэтому обслуживание только данных требует одинакового кол-ва чтений и записей, с WAL/REDO тоже самое.

Остаются как-бы только индексы, т.е. разница должна быть только из-за них. И вроде-бы логично, что условный «постгрес» будет медленнее, так как апдейт через COW требует изменения указателя на запись (обновление номера страницы). Однако, нужно смотреть все слагаемые:

• без COW требуется запись в undo.
• если при апдейте изменились индексированные колонки (что довольно часто), то какие-то индексы всё-равно придется менять.
• инсерты и удаления всё-рано требуют изменения индекса с координатами записей.

Соответственно, суммарно какая-то разница конечно есть, но вовсе не всегда в минус, и тем более не в два раза. Собственно некоторые цифры есть в wiki, ну и вот.

Есть возражения. Ты можешь привести сценарий, где нужно будет читать много старых данных? Смысла в этом мало потому, что менять-то их нельзя - они старые, база уже уехала вперед.

Чуть менее чем любая «долгая» читающая транзакция должна читать «старые», соответствующие своему MVCC-снимку. Если на фоне этой транзакции происходит много апдейтов, то начинаются проблемы. Только стоит учитывать, что понятие «долгая» тут может быть сильно растяжимым. Для простоты можно считать, это это некий fullscan терабайтной таблицы при построении мега-отчета на некий момент времени.

Не просто так Interbase, Oracle, MS SQL выбрали именно модель с логом возврата - два последних в итоге стали лидерами рынка, потому что двухкратный рост производительности записи на дороге не валяется.

Ну лидерами рынка они стали не поэтому, и «не просто так» в PostgreSQL выбрали COW. Двукратной разницы в производительности нет. Точнее говоря, его нет в среднем, а в каких-то отдельных сценариях каждый из вариантов может быть быстрее (пожалуй и более чем в два раза).

«Считать содержимое записи; записать измененную копию в новое месте; считать все индекса для этой записи; записать копию индексов с измененным указателем на новую запись» против «Считать запись; записать в нее новое значение; записать разницу в лог отмены» Может быть, без индексов постгрес будет работать с равной скоростью. Только какой же постгрес работает без индексов? Там как минимум по основному ключу всегда есть индекс.

Ну вот не совсем так, мягко говоря. Запись реализуется по-странично, поэтому обслуживание только данных требует одинакового кол-ва чтений и записей, с WAL/REDO тоже самое.

Остаются как-бы только индексы, т.е. разница должна быть только из-за них. И вроде-бы логично, что условный «постгрес» будет медленнее, так как апдейт через COW требует изменения указателя на запись (обновление номера страницы). Однако, нужно смотреть все слагаемые:

• без COW требуется запись в undo.
• если при апдейте изменились индексированные колонки (что довольно часто), то какие-то индексы всё-равно придется менять.
• инсерты и удаления всё-рано требуют изменения индекса с координатами записей.

Соответственно, суммарно какая-то разница конечно есть, но вовсе не всегда в минус, и тем более не в два раза. Собственно некоторые цифры есть в wiki, ну и вот.