CftClub.ru

[lil007]

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

Мне сказали, что можно по ID сессии как-то подрубится, через девелопер к сессии и посмотреть план запроса (это если я правильно постановку вопроса понял).

Как это сделать?

[Volod]

Если проблема только у одного юзера - м.б. настройка Количество строк в запросе - любят юзеры большое кол-во строк настраивать

[lil007]

[Volod]

Select sql_id from v$sql
where sql_fulltext like '%Z#MAIN_DOCUM%';

Select * from v$sql_plan where sql_id='7ffjqc8yd0073'

[Эмиралька]

[pabrz]

Обратите внимание на фильтры.

Последняя опция коллег из ЦФТ на эту тему была связана с тем, что при обращении к представлению через фильтр заполнялась служебная таблица.
По каждому пользователю.
Каждый раз.

Почему это делается?
Потому что блок where теперь не умеет в функции.

Поэтому гениальное решение: в фильтре сделать заполнение служебной таблицы, с которой потом делаем join и получаем отфильтрованные данные.

Решение, мягко говоря, спорное. Посмотрите свой случай на подобный феномен.

[Эмиралька]

[pabrz]

Пока в большинстве случаев так и делаем: рефакторинг функций и перевод в sql. Иногда для сокращение объема через макросы, но это только визуальное сокращение - де факто объем будет тот же, так что всегда есть шанс перешагнуть лимит объема текста представления.
Есть еще мысль делать представление с колонками-функциями, а потом второе селектом из нее, но не пробовал пока, есть ненулевой шанс, что не сработает, то же самое касается функциональных реквизитов.

Куда больше жаль сложные конструкции, вроде трехмерных представлений (инструкция model), которые, очевидно, перестанут поддерживаться полностью. Postgree в них не умеет. Вот их заменить просто нечем.

[pabrz]

Таки появилось что добавить по этой теме.
Я тут намедни подобный вопрос решал, и он чудесно решается теми самыми конвеерными функциями, про которые недавно в соседней теме говорили. На удивление, примеров в коде от ЦФТ на эту тему вы с большой вероятностью не найдете.

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

Почему последнее? Потому что конвеер это не лучшая штука для оптимизации, поэтому если мы по каким-то причинам должны показать не все подряд данные, то фильтр нам нужен уже там, сразу же, чтобы конвеером не жевать всю таблицу.

Дальше все довольно просто:

Мы делаем внутренний record со всеми колонками, которые будем считать в конвеере+ID объекта, для связи потом в основном селекте представления.

А дальше просто цепляем конвеер в представлении обычным join. В результате чего автоматически накладываем фильтр на представление ( в конвеере фильтрация как раз и делается) и просто вытаскиваем все нужные нам поля в готовом виде.

Господа из ЦФТ идею тоже одобрили.

Ограничения и минусы:
1. Оптимизация. Как я уже говорил, конвееру надо жевать максимум записей. Насколько шустро тут отработает DBI вопрос открытый, ибо согласно комментариям ЦФТ - там обычный BIND.
2. Надзапросы нельзя. Т.е. над полученным селектом с конвеером сверху накручивать второй селект уже нельзя. В остальном все вполне прилично.

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

Таким образом на выходе мы получаем вьюху вида

[Эмиралька]

[pabrz]

Да вроде можно. Не ясно правда как это в перспективе на скорость работы повлияет, особенно в DBI. Коллега мой туда вообще ID записи из основного селекта передает в качестве параметра . В этом примере - то самое a1(%id).

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

Конвееру всегда проще набрать свой пакет записей, чем построчно от селекта принимать. Пока нам оптимальным видится передача конвееру ключевых параметров для фильтрации (которые зададим на начальном этапе через операцию фильтра), а не полей запроса.
Т.е. конвееер - сам по итогу и является блоком where по совместительству.

Технически - вариант с полями работоспособен. Архитектурно - есть вопросы.

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