Мой подход (отделить/сузить запрос до необходимых колонок, отделить форму выбора заказчика от тяжеловесной формы редактирования реквизитов заказчика) принес некоторые результаты, но не дотягивает до цели в 0.5-1 секунды, и не является универсальным.

Список заказчиков - это только один из списков. Существуют другие списки, где сотни тысяч строк, и которые клиент сегодня тоже позволяет вывести на экран (в том числе и для экспорта в эксель). Даже если я экстраполирую свой подход на те случаи, получается время порядка 30-40 секунд. Сегодня неудачно выставленный фильтр может подвиснуть "экран большой таблицы" на 30-40 минут.

Думаю, как сделать за полсекунды.

Значит придётся программировать background fetch.


Да, похоже на это.

Самое очевидное для меня решение - не строить форму/грид/запрос с нуля каждый раз,
а показать спрятанную с прошлого раза, и уже после показа обновить по дельте (маленкий фетч).
Кэширование грид контроля (а не только датасета) позволяет избежать задержек его исполнения.

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

Запрос в общем случае считается тяжеловесным, секунды.
Дельта-запрос который касается только измененных строк - на 2-3 порядка быстрее,
но чтобы построить дельта-запрос, надо знать какие строчки, а для этого нужен полный запрос.

Давайте будем с уважением относиться к собеседникам. Я исключил сеть как цель для оптимизации на основании полного контекста, который нет смысла здесь представлять. С задачами оптимизации сетевой передачи данных я хорошо знаком, учебник написал.

Что важно, я упомянул: сеть пропускной способностью в гигабиты, все компоненты звена в одном дата центре, и измерение данных показало, что в них не попала "шелуха", т.е. их размер сочетается с моими ожиданиями. Соответственно, места для оптимизации на стороне сети мало. То, что есть, работает близко к оптимальному режиму для моей задачи.

Вроде, придумал. Основано на книжных знаниях, поэтому как получиться - покажет практика.

Исходные: медленный запрос "заказчики" с 20 тыс строк на 100 колонок, многие вычисляемые
Исполнение запроса: 10сек. Обработка на сервере - пренебрегаем (около 0.1 сек), заполнение контролов и грида - 2 сек.
Все вместе, если тянуть все колонки - 12 сек. Если тянуть только дешевые колонки - 2 сек (SQL срабатывает мгновенно)
Цель - моментально показать список заказчиков, с возможностью показа некоторых медленно вычисляемых полей.

Шаг 1: заменить медленный запрос на materialized view, "fast update on commit". Мой 11.2 вроде это умеет.
Теперь SQL сам будет построчно править вью, поддерживая полный список заказчиков готовым для запроса.
Это почти до нуля снижает скорость запроса, общее время - 2 сек из-за медленных виджетов клиента.

Шаг 2: Научить клиента вместо убивать/создавать форму, прятать/показывать собранную форму и само-синхронизироваться с (1).

Если не найду грид-виджет с само-синхронизацией, остается вариант более трудоемкой дельты вручную:

Шаг 3: раз в сутки(неделю, час) снять копию данных materialized view. Назовем их "ночной список заказчиков". От ночного списка строятся дельты.

Шаг 4: Научить клиента принимать дельты для построчной коррекции.

(1) проще всего. (2) выходит за рамки раздела Оракла. (3) может быть тоже materialized view, update on demand

Это должно позволить вызвать поп-ап за <= 0.2 секунды, что в глазах пользователя приравнивается к мгновенному.

После нескольких неудачных попыток, получилось создать первое представление с "fast update on commit".

Написал пару скриптов из двух сессий, пытаясь "споймать" промежуток времени между обновлением таблиц-источников, и обновлением моего представления, не словил. Ощущение, что обновление происходит синхронно.

Материализованные представления почему-то описываются в контексте "складов данных", непохоже что они используются часто в других ситуациях, но вот пригодилось. В моем случае, эта фича работает в точности как я ожидал, в 10 раз ускоряя клиентский запрос.

Были дополнительные улучшения в этой области в 12.х (возможность записи в материализованное представление), но придется с ними повременить.

Поделюсь, что узнал и испытал про MV.

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

Когда я добавил оптимизированные обновления по SCN, появились доп ограничения, довольно эзотерические.

Например, если есть селф джойн, то запрещен внешний джойн. Анси джойн просто запрещен для refresh fast on commit with SCN. Пришлось плюсики ставить.

В итоге, скорость чтения возрасла в пять раз (согласно autotrace), скорость записи не проверял, т.к. они строка в минуту или меньше.

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