просто above работает только со значениями текущей выборки, т.е. буквально показывает значение формулы из предыдущей строки массива. Например, если выбрать 1 месяц, то продажи за предыдущий месяц не покажутся, потому что у формулы продаж не будет предыдущего занчения. Если выбрать месяцы не подряд,типа январь и август, то для августа прошлыми продажами будут продажи января

календарь накопительного итога этого позволяет избежать

По максимальным - сколько смогут обеспечить исходя из имеющегося бюджета))

ну, понадеюсь пока, что хватит above... не хочется усложнять модель данных + на сколько я помню, с календарём придётся во всем формулы добавлять что-то типа flag = 1, или типа того... а у меня там их под 500 примерно...

Чем быстрее дисковая подсистемав целом, тем быстрее любые операции загрузки/сохранения. Это не нужно в процессе интерактивной работы пользователя, но на процедуры обновления/подготовки данных дисковые операции влияют непосредственно

это очень странно если честно

подтверждаю слова Евгения, хоть и странно, но факт

магия оптимальной загрузки

Это не странно. Это существенно зависит от конфигурации оборудования

На определенных кейсах точно :)
Мне на одном проекте пришлось так делать и было снижение времени работы.

вот вот. У меня например на тесте это дало замедление)

ну на сколько я понимаю, резидент может отработать быстрее если на сервере стоит ОЧЕНЬ мощный проц, но ОЧЕНЬ медленные диски?

а точно оптимальная загрузка была потом из файла? у меня просто ни разу не было такого чтобы резидент отрабатывал быстрее оптимальной загрузки... я ваще слабо представляю, что может отрабоатать быстрее оптимальной загрузки =)))) там миллиарды строк секундами грузятся =)

100%

тогда ещё страннее =))))

А какое количество записей ? Пока в резиденте меньше нескольких миллионов можно, как мне кажется, не заморачиваться.

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

до тех пор, пока не появятся еще задачи на это же время с резидентными загрузками.

Я вот до сих пор не понимаю. Вот смотрите - есть два варианта:
1) RESIDENT
2) сохранить в QVD, загрузить из QVD
Второй вариант быстрее если оптимизированная загрузка. а не построчная. Ок. Значит никаких where, никаких выражений в LOAD фразе - только грузим поля или не грузим поля и переинование. То есть фактически мы создаем копию таблицы с частью (или всеми полями). Это вообще зачем такое делать? Я в том смысле что все равно в 90% случаев придется этиу загруженную оптимально из QVD таблицы построчно обрабатывать. Или даже построчная загрузка из QVD быстрее RESIDENT ????

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