или все же выгрузит значения в БД объединит их там и результат загрузит в табло

не совсем понятен ответ

Все на стороне БД

спасибо!

тогда исходя из Ваших ответов у меня вытекает др вопрос, если на стороне БД все 3 вьюшки отрабатывают оптимально быстро, но при загрузке в табло начинается очень долгая загрузка, в какую сторогу смотреть? Экстракт делается не онлайн..

в данном случае источника, самой базы данных. Верно?

Надо смотреть в стороны пропускной способности. Например убирать тяжелые поля или оптимизировать БД на отдачу

есть ли в табло какие то тюнинг параметры, для более быстрого экстракта, или распараллелить как то можно?

у меня был случай когда на оракле к запросу добавили parallel сократил время формирования запроса с 2 часов до 40 минут

в том то и дело, что там порядка 30 мил записей

на уровне БД вроде как все норм, I\O система не провисает, а вот табло не может быстро забрать.. около 10-15 мил в час

Тюнить можно с помощью tdc. Ну или с профессионалами в конкретной БД.

как то на уровне табло можно что то подкрутить(тюнинг)

что такое tdc ??

какие то метрики в табло есть, т.к. бывает и 20 мил в час загружает а бывает и 10 мил.. хотя между собой запросы практически одинаковые.. вот и решил уточнить, на чьей стороне выполняются связи.. как понял на стороне БД.  Но почему табло так медленно выгружает, если запрос уже отработан, или какие то внутренние процессы создаются на БД и у них есть какой то буффер(кеш сайз или еще что то) что бы моно было увеличить..?

https://github.com/tableau/connector-plugin-sdk вот здесь

Можно ещё настройки драйвера поискать, у некоторых драйвером есть параметр fetch size, определяющий объем данных. И убрать все лишние поля

когда речь идет о десятках миллионов записей возможно уже стоит задуматься о Hyper API

это так же табло, или какой то другой продукт, извините просто новичок в этих делах пока что...

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