В смысле никаких блокировок? Блокировки при любой записи есть и на уровне платформы (управляемые) и на уровне СУБД (страница индекса). Но если писать по одной записи, то время блокировки минимальное и время пересечения с другими сеансами маленькое или нулевое.
Для сведения: менеджер записи медленный потому, что выполняет всегда 2 записи - сначала удаление (пишет пустой набор с отборами по всем измерениям), потом добавление (пишет набор с теми же отборами и записью). И это избыточно, т.е. лучше писать один набор с теми же отборами с одной записью/пустой, но в режиме перезаписи.

Набор записей тоже делает сначала удаление. Менеджер записи просто обертка над НаборомЗаписей

В смысле никаких блокировок? Блокировки при любой записи есть и на уровне платформы (управляемые) и на уровне СУБД (страница индекса). Но если писать по одной записи, то время блокировки минимальное и время пересечения с другими сеансами маленькое или нулевое.
Для сведения: менеджер записи медленный потому, что выполняет всегда 2 записи - сначала удаление (пишет пустой набор с отборами по всем измерениям), потом добавление (пишет набор с теми же отборами и записью). И это избыточно, т.е. лучше писать один набор с теми же отборами с одной записью/пустой, но в режиме перезаписи.

В смысле никаких блокировок? Блокировки при любой записи есть и на уровне платформы (управляемые) и на уровне СУБД (страница индекса). Но если писать по одной записи, то время блокировки минимальное и время пересечения с другими сеансами маленькое или нулевое.
Для сведения: менеджер записи медленный потому, что выполняет всегда 2 записи - сначала удаление (пишет пустой набор с отборами по всем измерениям), потом добавление (пишет набор с теми же отборами и записью). И это избыточно, т.е. лучше писать один набор с теми же отборами с одной записью/пустой, но в режиме перезаписи.

И что такое режим перезаписи? Набор или добавляет записи, или удаляет+добавляет. Апдейтов нет.
Менеджер записи - это тот же набор. А медленный из-за количества транзакций, а не из-за чего-то ещё.

Понятно же что в исходном посте имелись ввиду конфликты блокировок.
При 2000 usr можно в одно место засунуть скорость, если будут конфликты.
По 1000 записей писать - это ой как много. Подбирается эмпирически. Иногда больше 50-200 уже нет прироста скорости, а ожидания на блокировках огромны.
Вообще, прежде чем разгружать о скорости, нужно решить задачу в разделении пространств чуть менее варварским способом, чем все измерения (хотя и этого не всегда хватает)

Конфликты блокировок сложная тема. Тут нет тривиального решения.
С точки зрения ожиданий на блокировках 1000 записей это не много, если блокируется 1 страница индекса и много, если блокируется 1000 страниц индекса.

Транзакция одна в любом случае.
Менеджер записи - не набор, а объект который создает и записывает 2 набора.
Да, перезапись - это удаление+добавление, где удаление не всегда вносит изменение (строки может не быть).
Из-за чего менеджер записи работает медленно я уже написал.

Без комментариев. Тогда набор тоже пишет два набора.

Набор записей делает операции за 1 "прикладной" раз, а менеджер записи за 2. Поэтому срабатывают все прикладные подписки на события и платформенные. Кроме того, и менеджер управляемых блокировок вызывается дважды. По сравнению с этим всем 2 команды СУБД delete+insert для одной строки отнимают лишь немного больше, чем одна из этих команд СУБД.

Слушьте, люди - а вот в вашем эпичном споре про "наборы записей" и пр. по тексту - все таки, итог то какой прикладной? Подведет кто-то может, а то дискасс знатный, а я чот не понял - в итоге к чему уважаемое сообщество пришло то?

"Набор записей делает операции за 1 "прикладной" раз, а менеджер записи за 2. Поэтому срабатывают все прикладные подписки на события и платформенные" // Ошибаешься

Да ошибся. Описанное поведение относится к записи из формы при перезаписи (похоже особенность поведения формы). При перезаписи из кода поведение такое же, как запись набора записей со всеми измерениями.

Ничего нового от того, что уже написано в букварях, нет: "технически" МЗ в лучшем случае такой же как НЗ, в худшем - медленнее.

Спасибо, сохраню себе в закладках сухой вывод, а то из дискасса непонятно - все таки, кто ж прав, кто виноват :)

Не забываем, что краткость / понятность кода тоже дорогого стоит, поэтому слепо отвергать МЗ не стоит)

Я не применяю обычно менеджер записи. Так сложилось на практике, когда нужно обновлять порциями, в том числе многопоточно. Сейчас уже точно не помню почему был сделан отказ от менеджера записи в сторону набора записей, но причина точно была. Исследовались оба варианта решения.
Вообще, когда на прикладном уровне возникает проблема производительности, понятность это то, чем обычно приходится жертвовать.