Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2004.01.16;
Скачать: CL | DM;

Вниз

Хранимые процедуры IB   Найти похожие ветки 

 
alex-xx   (2003-12-18 20:32) [0]

Здравствуйте уважаемые!
Есть две серверные проседуры, возвращают они одно и тоже, но по отрабтке (по времени и по сжиранию ресурсов) это "небо и земля" объясните, кто может, почему так? Ниже листинги хранимых процедур.

Процедура 1 (очень медленная и ресурсоемкая)

CREATE PROCEDURE SUM_NACH_ABTRAF_CEPOTHKA (
KOD INTEGER,
DATE_S DATE)
RETURNS (
NACH_AB_TRAF __MONEY)
AS
begin
/* Procedure Text */
SELECT sum(nachisleniy.summa) as NACH_AB_TRAF
FROM nachisleniy
WHERE (nachisleniy.kod_ab in (select cepothka.kod from cepothka(:KOD))
and nachisleniy.date_mount<=:DATE_S)
into :NACH_AB_TRAF;
suspend;
end

Процедура 2 (быстрая)

CREATE PROCEDURE SUM_NACH_ABTRAF_CEPOTHKA_1 (
KOD INTEGER,
DATE_S DATE)
RETURNS (
NACH_AB_TRAF __MONEY)
AS
DECLARE VARIABLE KODDD INTEGER;
DECLARE VARIABLE SUMMA __MONEY;
begin
/* Procedure Text */
SUMMA=0;
NACH_AB_TRAF=0;
for
select cepothka.kod from cepothka(:KOD)
into :KODDD
do
begin
SELECT sum(nachisleniy.summa) as NACH_AB_TRAF
FROM nachisleniy
WHERE (nachisleniy.kod_ab =:KODDD and nachisleniy.date_mount<=:DATE_S)
into :SUMMA;
if (SUMMA is null) then begin SUMMA=0; end
NACH_AB_TRAF=NACH_AB_TRAF+SUMMA;
end
suspend;
end


 
Johnmen ©   (2003-12-18 21:40) [1]

Потому, что
- селект из процедуры выполняется гарантированно один раз в №2, а в №1 возможно столько, сколько записей в nachisleniy (зависит от оптимизатора)
- в №1 вследствии наличия предиката IN будут последовательно перебираться значения в нём, в №2 такого безобразия нет

Чтобы ещё ускорить, можно обойтись просто запросом

SELECT sum(N.summa) as NACH_AB_TRAF
FROM cepothka(:KOD) C
JOIN nachisleniy N ON N.kod_ab=C.kod
WHERE N.date_mount<=:DATE_S


Про оптимизацию запросов читай krista.ru


 
Alex-xx   (2003-12-18 23:02) [2]

Спасибо! Пойду читать про объединения и ортимизацию....:)


 
Alex-xx   (2003-12-18 23:17) [3]

Щас попробывал Ваш запрос - анализ производительности дал тот же результат, что и процедура №2
(может быть это упростит код, а не ускорит отработку? или я не прав?) если не прав, то за счет чего произойдет ускорение?


 
Johnmen ©   (2003-12-19 09:42) [4]

Я предвидел такой вопрос...:)
Ускорение крайне незначительно (в %%) и практически его заметить трудно. Происходит за счет отказа от "промежуточных" операций.


 
alex-xx   (2003-12-19 10:10) [5]

Я придвидел такой ответ... :)
В связи с чем следующий вопрос.
Вы на 100% уверены, что JOIN...ON выполняет меньше промежуточных операций чем описанная выше конструкция?


 
Johnmen ©   (2003-12-19 10:17) [6]

Я уверен на 99%, что его "промежуточные" операции "короче" :)
Чтобы глубже понять и "прочувствовать" надо все-таки почитать на krista.ru


 
alex-xx   (2003-12-19 10:21) [7]

Убедили! Спасибо! Пойду почитаю...



Страницы: 1 вся ветка

Текущий архив: 2004.01.16;
Скачать: CL | DM;

Наверх




Память: 0.48 MB
Время: 0.028 c
8-49643
BANAN
2003-09-09 16:24
2004.01.16
z-буфер


3-49392
Floppy
2003-12-19 16:53
2004.01.16
Сортировка в лукар поле


14-49762
PVOzerski
2003-12-24 10:23
2004.01.16
Федорино горе, или о забавных нелепостях в названиях программ


3-49458
sirin
2003-12-18 03:32
2004.01.16
DBEDIT


8-49644
simmoril
2003-09-17 06:56
2004.01.16
Координаты отмеченных пикселей в bmp-файле