iBase.ru Forum

при переходе на 1.5.1 заметили уменьшение скорости следующего запроса:

select d.PKey, h.ClientID, r.Cnt as Rest
from WaybillD d, WaybillH h, Goods g
LEFT JOIN Rest r ON g.GoodID = r.GoodID
where h.PKey = d.DocID and h.Typ in (1, 21) and d.GoodID = g.GoodID and d.Cnt > 0
and h.ClientID = 1702
and d.PKey not in (select distinct DataID from wd_certificates)
;

скорость выполнения:
FB 1.5.1 (FB-V1.5.1.4481 Firebird 1.5):
время выполнения - почти 8 минут

FB 1.0 (FB-V6.2.908 Firebird 1.0):
время выполнения - 4 секунды

FB 1.5.1 и 1.0 стоят на разных машинах (по скорости процессора первая раза в три медленнее. скорость работы с диском - примерно одинаковая), так что на абсолютное время тестов не обращайте большое внимание. перенос базы с 1.0 на 1.5.1 делался через только backup/restore (может я неправ?).

если из запроса убрать "d.PKey not in (select distinct DataID from wd_certificates)" то результаты такие:

скорость выполнения:
FB 1.5.1 (FB-V1.5.1.4481 Firebird 1.5):
время выполнения - 3 минуты

FB 1.0 (FB-V6.2.908 Firebird 1.0):
время выполнения - 5 секунд

смущает такая большая разница для версии 1.5.1... есть идеи как можно ускорить выполнение именно этого запроса на 1.5.1 ?

индексы после переноса вроде бы активны. во всяком случае, запрос

SELECT RDB$RELATION_NAME, RDB$INDEX_NAME, RDB$INDEX_INACTIVE
FROM RDB$INDICES WHERE RDB$RELATION_NAME NOT STARTING 'RDB$'
ORDER BY RDB$RELATION_NAME

возвращает поле RDB$INDEX_INACTIVE равное 0

select d.PKey, h.ClientID, r.Cnt as Rest
from WaybillD d, WaybillH h, Goods g
LEFT JOIN Rest r ON g.GoodID = r.GoodID

НЕЛЬЗЯ МЕШАТЬ В КУЧУ ЯВНЫЕ И НЕЯВНЫЕ JOIN

> если из запроса убрать "d.PKey not in (select distinct
> DataID from wd_certificates)" то результаты такие:
> FB 1.5.1 (FB-V1.5.1.4481 Firebird 1.5):
> время выполнения - 3 минуты
> FB 1.0 (FB-V6.2.908 Firebird 1.0):
> время выполнения - 5 секунд

Попробуй поэкспериментировать с запросом без "not in":
избавься от крамольного смешения явных и неявных этих самых,
сравни планы и время выполнения на обоих серверах.

to sag:
без NOT IN работает быстрее (на 1.5.1). но ведь на 1.0 работает быстро в любом случае.

следует ли считать, что такое изменение времени выполнения при переходе на новую версию - нормальное явления?

to kdv:
знаю, что запрос "не очень корректный" но ведь работало же быстро... если бы с самого начала тормозило на версии 1.0 - тогда я дурак. а так кого винить?

> без NOT IN работает быстрее (на 1.5.1). но ведь на 1.0
> работает быстро в любом случае.

Это называется быстрее?! FB 1.5.1 - 3 минуты, FB 1.0 - 5 секунд, Разница то огроменная! Вот я тебе и предлагаю тебе для начала с упрощенным вариантом разобраться, но в правильном написании.

> следует ли считать, что такое изменение времени выполнения при
> переходе на новую версию - нормальное явления?

Нет, в общем случае это не нормально. Но изменился оптимизатор, который улучшился, но не стал идеальным.

> знаю, что запрос "не очень корректный" но ведь работало
> же быстро...

После перехода на 1.5 уже на эксплуатирующейся системе нашел у себя в приложении запрос со смешением явного с неявным. Скорость запроса не ухудшилась. Но за ради правильности запрос был переделан.

> если бы с самого начала тормозило на версии
> 1.0 - тогда я дурак. а так кого винить?

Ставлю на то, что твой запрос по разному "планируется" единичкой и полуторкой.[quote][/quote]

Anonymous писал(а):следует ли считать, что такое изменение времени выполнения при переходе на новую версию - нормальное явления?

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

действительно, виноват был кривой запрос. переделали - стал выполняться 13 секунд на FB 1.5.1
Всем спасибо за советы.

если кому интерестно - запрос вот:

SELECT WAYBILLH.TYP, waybilld.pkey, WAYBILLH.DOCUMENT, WAYBILLH.dat,
waybillh.clientid, WAYBILLD.GOODID, goods.goodid, goods.barcode,goods.unit,
waybilld.CNT, waybilld.costprice, waybilld.costbuy, waybilld.tax,
wd_certificates.CERTIFICATE, rest.cnt
FROM WAYBILLH
INNER JOIN WAYBILLD ON (WAYBILLH.PKEY = WAYBILLD.DOCID)
LEFT OUTER JOIN WD_CERTIFICATES ON (WAYBILLD.PKEY = WD_CERTIFICATES.DATAID)
inner join rest on (rest.goodid = waybilld.goodid)
inner join goods on (goods.goodid = waybilld.goodid)
WHERE
(
(WAYBILLH.CLIENTID = 1702)
and
(WD_CERTIFICATES.DATAID IS NULL )
)
;

Dmitry писал(а):действительно, виноват был кривой запрос. переделали - стал выполняться 13 секунд на FB 1.5.1
Всем спасибо за советы.

А на FB 1.0.х скока времени выполняется запрос?

у меня есть сомнения в правильности расположения таблиц в явном join в отношении их размеров. явный join выполняется по очереди по парам таблиц "сверху вниз". если есть возможность покрутить - попробуй. смотри на планы, и на page reads/fetches from cache.

Dmitry писал(а): FROM WAYBILLH
INNER JOIN WAYBILLD ON (WAYBILLH.PKEY = WAYBILLD.DOCID)
LEFT OUTER JOIN WD_CERTIFICATES ON (WAYBILLD.PKEY = WD_CERTIFICATES.DATAID)
inner join rest on (rest.goodid = waybilld.goodid)
inner join goods on (goods.goodid = waybilld.goodid)

Если перенести LEFT JOIN в самый низ, то скорость должна возрасти.