Не сравнивали ключи в Hash128() завернуть, а потом уже group by?

now() не показывает время?

именно данная резидентная загрузка 50 минут? без всего остального?

Да

Members таблчка, в ней наверное 270 столбцов? И сама она занимает 2 гб на диске в QVD?

я так понимаю там в принципе уникальных сочетаний очень много, точно ли оперативки хватает и не уходит в файл подкачки в процессе расчета?

1ТБ всего, они конечно заняты, но не на столько

1Гиг, около 100 столбцов.
Upd: даже около 60

2 варианта которые могут ускорить на этапе расчета:
1) попробуйте отдельно загрузить только эти 6 столбцов, а после уже резидентную загрузку.
2) резидентная загрузка с условием WHERE not exists (camp_id,context_member_id,subs_key) order by response_date desc, contact desc, said_yes desc. поля без группировки

есть ещё вариант с маппингом, но это выйдет во время на других этапах

Да там с источника только час лезет (oracle), а потом ещё group by 50 минут... в общем решу вопрос на стороне источника, там менее 10 минут вся логика с последующими запросами

Клик не распараллеливает обсчеты сам, поэтому массивные операции занимают много времени.
Можно попробовать сделать парамтеризированные скрипты загрузки и обрабатывать в несколько более мелких сегментов параллельными тасками, а потом всё законкатенировать.

Oracle > QVD > и потом уже ETL скрипта, я бы начал с этого.

Интересно, а как распараллелить внутри одного приложения?

Коллеги, добрый день!
Подскажите пожалуйста, почем при попытке использовать данные в variable input, невозможно выбрать имя поля?

Пишете qvs, переменными задаёте параметры, чтобы ваша большая таблица логически побилась на аналогичные, но меньшие по объёму.
Не уверен, что можно в таске передать параметр, но создать несколько одинаковых приложений, изменяя в нем только значения параметра - точно не большая проблема. В паблишере запускаете параллельно таски с каждым из этих приложений. По окончанию работы всех, конкатенируете результаты.
Это, безусловно, более трудоемко для разработчика, но время сократит существенно. Если ресурсы позволяют, конечно.
У нас расчёт остатков для кэшфлоу для разных версий так реализован, вместо последовательной обработки в пол часа, параллельная в 6 минут.

Понятно, подумаем, спасибо! Так мы наверное будем загружать с источника параллельными процессам, идея хорошая, за наводку отдельное спасибо! Но агрегировать проще на оракле в нашем случае. Лучше мы ускорим загрузку с него уже агрегированных данных наверное. Спасибо!

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

Коллеги, кто то может пояснить,: