Я в курсе оптимизации серверов и  конфигурирования БД .
И скажу что даже на магазинах по 300К тваров и сложнейших выборках размер и ibtmpl - точно не превышает не то что 300 ГБ а и 10.
А учитывая конечный результат сего запроса  ( отображение 200 строк  в небольшой табличке, да и  еще в тот момент когда ее отрисовывать никто не собирется.
Это на мой взгляд сомнительная оптимизация.
Но вы правы я не явлюсь специалистом  ни в drupal ни в оптимизации самих запросов mysql я веже линуксойд в превую очередь. Именно по этому хотел бы найти тут того кто сможет не в этом вопросе  разобраться,  и как не прискорбно разобраться это не показать мне где и как а самому, поскольку я реально оцениваю свои силы  этом клубке. Все на что хватает моего программинга на php это небольшие скрипты да правки шаблонов компанентов на битриксе.   НО сдаетсяч мне что для отображения вот этой таблички, таких объемов не требуется, тем более  в момент когда  ее вообще еще никто не просил показываться.

в принципе, есть модуль inline_form_errors в ядре, который худо-бедно заменяет браузерную валидацию

вы там в курсе, что такое сложность алгоритма?

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

странно слышать удивление, у нас всего лишь удвоились данные, а выборка стала работать хуже не кратно
ну вот так оно и работает, не кратно

выборка не стала работать ни в два ни в 20 ни в 200 раз медленней что да странно

если сложность квадратичная, то увеличение данных вдвое увеличивает обработку вчетверо
а там, напомню, 60 таблиц через джоины и селекты
и 8 сортировок

помимо быстрее/медленнее есть и другие критерии сложности алгоритма, например, потребляемые ресурсы

А ещё сложность может быть в нецелой степени

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

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

Если данные, получаемые запросом, не нужно. То зачем тогда его выполнять?

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

хотя это ж шестёрка, там вроде в разные таблицы по дизайну

в шестёрке единичные поля в одну сваливались по типу, множественные в отдельные, да

да вот собственно я и ищу человека который в состояние это сделать.  я трезво понимю что тут нужен человек с практикой в самом друпале.
И то что код кривой скорее всего так и есть, по крайней мерие пока я верстку на "адаптив" переводил плевался как мог.
и То что сайт в конечном итоге юзает 4 БД на мой взгляд тоде немного перебор для такого проекта.
Вот это только  не решает главную проблему. Нужно найди разраба на друпал, можно  даже на пост основу, поскольку этот проект толко  в след месяце пойдет на рефакторинг, то есть еще пол года точно жить на этом. А там еще бэкэнд самописка чистая частично пересекается с друпал.

Есть кто желающий поработать с6 друпалом ? желательно с ценой/час

с 6 друпалом.

6+ самопись

а был уже рассказ как докатились до жизни такой?