YuRockЯ говорил, что concurrency тяжелее для сегвера
у меня есть статистика сервера, где у людей через 3 дня после рестора отвалилась транзакция роллбэком (застрял OIT), и там через год (при sweep interval 0 и незапуске вручную свипа) на на каждый снапшот (на классике) выделялось 27мб TIP. Никто ничего не заметил.
Вы когда говорите "тяжелее", выражайтесь точнее, с конкретными примерами "тяжелости".

YuRockТяжелость наступает при накоплении мусора, и при его чистке.
не надо пороть ... всякое.
Я на курсах регулярно говорю, что количество версий и количество транзакций никак не связано. 1млн транзакций может вообще не породить ни одной версии, и наоборот, 1 транзакция может породить 1млн версий.
И OIT тут вообще ни при чем. Её значение сильно преувеличено. Это лишь индикатор того, что ГДЕ-ТО в базе случился роллбэк, и МОГУТ БЫТЬ версии которые надо удалить. А могут и не быть.
Поэтому застревание OIT вообще никак не влияет на производительность, кроме увеличения размера снимка TIP при старте snapshot. А TIP линейный, и его сканирование или изготовление снимка не сильно тормозит сервер.

На текущий момент все проблемы с производительностью, которые мы наблюдаем, заключаются в основном
- в неоптимизированных запросах - либо большое кол-во натуральных чтений, либо большое кол-во индексных чтений
- слишком частое выполнение коротких запросов, которые "задалбывают" сервер, убивая до 60% производительности.

Проблем с застреванием oit, или еще чем-то мы тут не наблюдаем вообще. Да, бывают случаи, когда "админ заснул в ИБЭксперте" на пару суток, тогда накапливаются версии и получаются тормоза. Но это решается скриптами "убиения" подобных коннектов через mon$. Еще бывает "внезапная репликация" программными средствами, тогда да, количество page writes превышает page reads в десятки раз. Но это всё экзотика. И опять же, влияние старта транзакций RC/Snapshot тут вообще никакое.

Старый плюшевый мишкаА через 15 лет понёс противоположную ахинею
што??? че-то вы, господин хороший, меня обвиняете непонятно в чём. Я пока насчет read committed read consistency вообще никак не выражался, совсем. Ибо у меня нет данных о полезности этого режима. Я хотел (на днях) его потестить, но меня отговорили. И я пока не придумал, как ЭТО тестировать. На реальных системах у нас пока нет перешедших на 4.0. Но мы попробуем организовать "предтесты", чтобы понять, насколько измененная сборка мусора работает. Однако, не могу обещать, когда такое получится. Нет у нас еще клиентов на 4.0. Хотя есть, которые уже хотят перейти.

Старый плюшевый мишкаПлюнь в меня плиз TPB от этого чуда RC RC
чем плевать-то, если в 4.0 старая RC теперь стала RC со стабильными курсорами. Ась?
Так что с точки зрения приложений ничего не меняется. Просто они начинают при селектах в RC получать более "консистентные" результаты. И фсё.
(вернуть можно в firebird.conf).

YuRockВсего лишь предлагал доделать минимальную доработку, которая, по моему мнению (мне - точно) облегчила бы переход на 4-ку.
Ну, раз "такие, как я, не нужны" - ладно, будем пользоваться всё равно :)
либо я чего-то не понимаю, либо тут какая-то ересь. Каким образом read committed read consistency может ЗАТРУДНИТЬ переход на 4ку? Вам вообще какая половая разница? Вы либо материтесь на "рост базы данных" с вашим нынешним управлением транзакциями, либо вообще ничего не замечаете.
С точки зрения приложений вам вообще ничего менять не надо. Не понравится rc rc - ну поменяйте в конфиге обратно. Что вообще за гонево какое-то про "облегчение перехода". Там с переходом основное это типы данных и их совместимость. Которая опять же, решается документом от Симонова.
https://www.ibase.ru/files/articles/firebird4/fb4migrationguide_rus.html