По эффективности

← →
}|{yk © (2004-08-06 16:48) [0]

Можно ли вот такой запрос
select plat_date, sum(summ_plat) summa from ( SELECT plat_date, summ_plat FROM (SELECT b.set_id, b.line_id, b.plat_date, SUM (b.summa) summ_plat FROM app_bank b WHERE b.unit_id IN ( SELECT mem_id FROM (SELECT a.set_id, a.mem_id, a.mem_pid FROM unit_tree a START WITH a.mem_id = :in_unit_id CONNECT BY PRIOR a.mem_id = a.mem_pid)) GROUP BY b.set_id, b.line_id, b.plat_date ORDER BY b.plat_date, b.set_id, b.line_id) zapyt WHERE zapyt.set_id = :in_set_id AND zapyt.line_id = :in_line_id AND zapyt.plat_date BETWEEN ADD_MONTHS (( TRUNC (LAST_DAY (TO_DATE (:in_date, "dd.mm.yyyy" ) ) ) + 1 ), -1 ) AND TRUNC (LAST_DAY (TO_DATE (:in_date, "dd.mm.yyyy"))) union SELECT (TO_DATE (:in_date, "dd.mm.yyyy") + ROWNUM - 1) plat_date, 0 summ_plat FROM all_objects WHERE ROWNUM <= EXTRACT (DAY FROM (TRUNC (LAST_DAY (TO_DATE (:in_date, "dd.mm.yyyy" ) ) ) ) ) ) group by plat_date order by plat_date
переписать более эффективнее?

← →
Sandman25 © (2004-08-06 16:50) [1]

Конечно, можно. Например, зачем нужен Order by во вложенном селекте?

← →
Sandman25 © (2004-08-06 16:51) [2]

Я тут еще немного поковырялся и могу добавить, что запрос ужасно написан. Как раз тот случай, когда Oracle c его select from (select) только вредит.

← →
}|{yk © (2004-08-06 16:56) [3]

Так, спасибо, а еще?

---
Жук - наш президент

← →
}|{yk © (2004-08-06 16:59) [4]

А что ужасного?

---
Жук - наш президент

← →
Sandman25 © (2004-08-06 17:02) [5]

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

← →
}|{yk © (2004-08-06 17:06) [6]

Почему? Мы изначально получаем только то, что нужно? Только потом добавляю дни, в которых не было платежей (с нулевыми платежами)

← →
Sandman25 © (2004-08-06 17:08) [7]

Неужели?

Почему бы
set_id = :in_set_id
AND line_id = :in_line_id
не засунуть в расчет zapyt?
Для начала...

← →
Sandman25 © (2004-08-06 17:10) [8]

Почему
SELECT mem_id
FROM (SELECT a.set_id, a.mem_id, a.mem_pid
FROM unit_tree a
START WITH a.mem_id = :in_unit_id
CONNECT BY PRIOR a.mem_id = a.mem_pid))
а не
(SELECT a.mem_id
FROM unit_tree a
START WITH a.mem_id = :in_unit_id
CONNECT BY PRIOR a.mem_id = a.mem_pid)
?
В-общем, повторяю еще раз. Переписать все нафиг :)

← →
}|{yk © (2004-08-06 18:11) [9]

От перестановки скорость не увеличилась. Как была 0,02 с, так и осталась

---
Жук - наш президент

← →
Sandman25 © (2004-08-09 10:32) [10]

[9] }|{yk © (06.08.04 18:11)

Нет, была 0.021, а стала 0.019 :)

Доктор сказал: "В морг", значит, в морг. (c)

[9] }|{yk © (06.08.04 18:11)
> От перестановки скорость не увеличилась. Как была 0,02 с,
> так и осталась

Это сейчас. А через пол-года - год, возможно, пользователи начнут вешаться со старых запросов. и будут они отрабатывать не 0.02 с, а 10 минут, например. Лучше сразу сделать правильно, а то обычная практика - при разработке все летает, при заполнении данными система начинает разваливаться из-за диких тормозов.

2[9] }|{yk © (06.08.04 18:11)
>Как была 0,02 с, так и осталась
А что хотелось бы в идеале? С минусом?

>Жук - наш президент
Чур меня. У нас своих жуков... 8-)

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

EXPLAINE PLANE поможет всегда.

Да, выборка делается по небольшому диапазону, всего 10 тыс записей.

---
Жук - наш президент

2[13] }|{yk © (09.08.04 11:35)
>Да, выборка делается по небольшому диапазону, всего 10 тыс записей.
В смысле "деревянная" выборка из 10 тыс? Так это не мало мягко сказать. Смотри план выполнения.

По эффективности Найти похожие ветки