формальные показатели включения cacheLookup EntireTable

[NetBus]

Хочется все таки понимания формально (сколько вешать в граммах)
как определить предел при котором можно выставить cacheLookup EntireTable
у требуемой таблицы.
из руководства
"
• параметрические (например, LedgerParameters): EntireTable;
• транзакционные (например, LedgerTrans): None;
• картотеки (например, InventTable): Found (объемная и часто
обновляемая картотека), EntireTable (статичная и небольшая);"
со статичностью и параметричностью все понятно, сложнее с понятием небольшая ...
Например 40 строк, — это много или мало? А количество столбцов играет роль? Если да, то какую?

Есть опыт и/или исследования по данному поводу?

MS SQL
DAX 2009

[Logger]

Я этот тип кеширования не люблю.
В 2009-й RU7 все еще есть проблема с синхронизацией этих кешей между аосами.

Вообще, физически аос хранит данные такой таблички во временной табличке.
Поэтому если она большая, то не стоит делать EntireTableCache
Также не стоит если регулярно обновляется.

Где то в руководстве видел рекомендацию что использовать EntireTableCache только на табличках до 2 тыс. записей.

[NetBus]

нашел кажется
Avoid using EntireTable caches for large tables because once the cache size reaches 128 KB the cache is moved from memory to disk. A disk search is much slower than an in-memory search.

[fed]

В качестве небольшого охотничего рассказа: Меня однажды позвали тьюнить производительность к клиенту. При этом у клиента даже на простых операциях (типа разноски тупого журнала платежей или журнала отборочных накладных по производственному заказу) утилизация AOS взлетала до 80-90%. Меня это крайне удивило, поскольку вообще это был первый случай в моей практике, когда узким местом был AOS, а не SQL Server.
Вскрытие показало, что партнер поставил Entire Table Cache на таблицу с 120-130 тысячами записей и при этом обновляемую раз 5 в секунду. В результате - два AOS и один батч сервер в замкнутом цикле перечитывали эту злостастную таблицу. При этом как только один цикл перечитывания заканчивался, тут же начинался второй (поскольку кто-то уже успел ее обновить во время перечитывания).
Надо сказать - что я эту ошибку диагностировал скорее по счастливой случайности, чем в результате планомерных действий. На SQL Server это перечитывание выглядело как Fetch Cursor - было тяжело понять что именно происходит и не часть ли это нормальной разноски. А обычная трассировка AOS никакой полезной диагностики вообще не приносила.
Поэтому я НИКОГДА не использую этот метод кэширования. Выигрыш по сравнению с FoundAndEmpty - копеечный, а риски - нехилые.