при переходе на 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
FB 1.5.1 vs FB 1.0 - уменьшение скорости (FreeBSD)
> если из запроса убрать "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":
избавься от крамольного смешения явных и неявных этих самых,
сравни планы и время выполнения на обоих серверах.
> 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 работает быстро в любом случае.
следует ли считать, что такое изменение времени выполнения при переходе на новую версию - нормальное явления?
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]
> работает быстро в любом случае.
Это называется быстрее?! FB 1.5.1 - 3 минуты, FB 1.0 - 5 секунд, Разница то огроменная! Вот я тебе и предлагаю тебе для начала с упрощенным вариантом разобраться, но в правильном написании.
> следует ли считать, что такое изменение времени выполнения при
> переходе на новую версию - нормальное явления?
Нет, в общем случае это не нормально. Но изменился оптимизатор, который улучшился, но не стал идеальным.
> знаю, что запрос "не очень корректный" но ведь работало
> же быстро...
После перехода на 1.5 уже на эксплуатирующейся системе нашел у себя в приложении запрос со смешением явного с неявным. Скорость запроса не ухудшилась. Но за ради правильности запрос был переделан.
> если бы с самого начала тормозило на версии
> 1.0 - тогда я дурак. а так кого винить?
Ставлю на то, что твой запрос по разному "планируется" единичкой и полуторкой.[quote][/quote]
В общем случае - нет. В твоем частном - тебе еще повезло. У многих смешанные явные и неявные джойны вообще отказываются работать. Чем новее сервер, тем он менее любит "некорректные" запросы.Anonymous писал(а):следует ли считать, что такое изменение времени выполнения при переходе на новую версию - нормальное явления?
-
Dmitry
действительно, виноват был кривой запрос. переделали - стал выполняться 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 )
)
;
Всем спасибо за советы.
если кому интерестно - запрос вот:
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 )
)
;
Если перенести LEFT JOIN в самый низ, то скорость должна возрасти.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)