afgmКуда ещё можно копнуть?Посмотри на загрузку CPU и IO, сравни.

PS Я мерял при стандартных для супера 2048 страницах кеша. Сама страница у меня 8КБ

afgm,

а теперь померяй в isql, и заодно приведи статистику коммитов

hvladafgm,

а теперь померяй в isql, и заодно приведи статистику коммитовЕсли не лень, то и с большим кешем тоже. Там будет интереснее.
Ну и наблюдай CPU\IO

afgm,

несколько подсказок:

- тест 1x10М делает коммит 1 раз, соотв. 1 раз пишет грязный кеш на диск, а вот тест 10х1М делает 10 коммитов

- во время коммита запись на диск происходит быстрее, чем во время выполнения запроса, отсюда пила во втором случае

- чем больше кеш, тем позже начнётся запись на диск и тем больше работы останется коммиту

- отдельно про "эффект IBE" : при расширении таблицы новые страницы PIP помечаются таким образом, что к их записи на диск приведёт коммит любой тр-ции (не обязательно нашей).
Из-за careful writes перед записью PIP нужно сначала записать все соотв. DP. Таким образом коммит любой тр-ии приведёт к записи всего кеша.
Нужно ли говорить, что после выполнения запроса IBE стартует и завершает несколько своих тр-ций, которые и пишут весь грязный кеш (а нам кажется, что это сделал наш запрос,
хотя в статистике этого и не видно)

Главное - я уверен, что в тесте 1х10М ты не увидел падения загрузки ни у CPU, ни у IO - а это означает, что скорость заливки не зависит от кол-ва записей заливаемых в одной тр-ции.
Это многократно подтверждается наблюдением за работой рестора, например.

Есть другие факторы, связанные с размером кеша и частотой коммитов, но заливка сама-по-себе никак не зависит от кол-ва записей (по крайней мере это не измеримо на практике).