> > хотя в запросах работала нормально, но так как
> > это была не фатальная потеря, и использовалось всего в одном месте
> > решил что проще обойтись.
>
> Просто надо закомментировать триггер, а после восстановления
> раскомментировать и перекомпилить
Пасиб ;) вроде уже догадался ;)
On 24 дек, 13:15, A7exander <[EMAIL PROTECTED]> wrote:
> Частично места где Yaffil молотит быстрее уже нашел.
> Есть простой запрос (таблица smoves - 3 млн. записей):
>
> select k.id_knames, sum(sm_quant)
> from smoves s, knames k
> where
> s.id_knames=k.id_knames and s.id_sklnames=1
> and k.nm_folder=0 and s.sm_date<:ost_date
> and k.nm_id_knames=1
> and k.nm_parent=1660
> group by k.id_knames
> having sum(sm_quant)>0
>
> на Yaffil отрабатывает всреднем 26 секунд
> PLAN SORT (JOIN (K INDEX (KNAMES_IDX2),S INDEX
> (SMOVES_IDX_SK_NM,SMOVES_IDX1)))
>
> на Firebird-2.0.3.12981 отрабатывает всреднем 140секунд
> PLAN JOIN (K ORDER KNAMES_IDX1 INDEX (KNAMES_IDX2), S INDEX
> (SMOVES_IDX_SK_NM, SMOVES_IDX1))
>
> НО! индекс SMOVES_IDX1 по полю s.sm_date нерезультативен, поскольку
> дата берется либо последняя либо близка к ней,
> и если заставить оба сервера не использовать его, заменив
> and k.nm_folder=0 and s.sm_date<:ost_date
> на
> and k.nm_folder=0 and coalesce(s.sm_date, cast('now' as
> date))<:ost_date
> то ситуация резко меняется - птица отрабатывает за 63мс а дятел за
> 110мс!
> тоесть у меня предположение что дятел быстрее молотит нерезультативные
> индексы,
> уже нашел несколько таких мест в своей БД. Прийдется поборотся с
> пережитками прошлого ;)
Кстати уже исправил два десятка запросов с вышеприведенным диагнозом,
вроде
все встает на свои места :) других аномалий пока не замечено
