iBase.ru Forum

Доброго дня!

Вот запрос: выдает около 800 записей (в таблице 47000) за секунду.
А вот этот: зависает навсегда .

Что это? Вроде в запросе все нормально или я переработал?

ЗЫ. У меня fb 1.5.2

Может этот (второй) запрос надо по другому писать?

а зачем тебе DISTINCT в подзапросе?

А вот этот?

dimitr писал(а):а зачем тебе DISTINCT в подзапросе?

Чтобы выбранные телефонные номера не повторялись , т.е. чтобы внешний запрос не напрягался сильно.

ЗЫ. Если внешний запрос запустиь без подзапроса, то получается около 4500 записей. Неужели fb в них так долго ищет "b.fone in"? Или я ничего не понимаю?

Merlin писал(а):А вот этот?

select distinct a.fone from atc a
where
where a.i_date >= '01.02.2005'
and a.i_date < '01.03.2005'
And
(a.fone like '8067%'
or a.fone like '8097%'
or a.fone like '8050%'
or a.fone like '8066%')

ОПА . А я и не знал, что такая конструкция прокатывает, вернее не предпологал . Большое спасибо, так все работает быстро!

ЗЫ. Но все же, ради любопытства, почему же мой запрос так тормозит?

ponyol писал(а):

dimitr писал(а):а зачем тебе DISTINCT в подзапросе?

Чтобы выбранные телефонные номера не повторялись , т.е. чтобы внешний запрос не напрягался сильно.

А ты бы попробовал, а не думал Если индекс по a.fone есть, конечно.

ponyol писал(а): ЗЫ. Но все же, ради любопытства, почему же мой запрос так тормозит?

Потому что его попросил ограничить выборку датами, а потом для каждой записи этой выборки сделать подзапрос и большую часть из неё выкинуть, вместо того, чтобы наложить все ограничения сразу.

Merlin писал(а):

ponyol писал(а): ЗЫ. Но все же, ради любопытства, почему же мой запрос так тормозит?

Потому что его попросил ограничить выборку датами, а потом для каждой записи этой выборки сделать подзапрос и большую часть из неё выкинуть, вместо того, чтобы наложить все ограничения сразу.

Дело в том, что выборка по датам дает всего лишь 3800 записей. Т.е. сервер из этого количества выберает 800 записей и чуть ли не умирает (99% проца и бесконечное время)? Питон с такой задачей (скриптом из десятка строк) справляется ну очень быстро (не засекал)! У меня есть ощущение, что fb сначала пытается выгрибать записи по всей таблице из подзапроса, а потом по датам. По другому эту тормознутось я объяснить не могу.

ponyol писал(а):

Merlin писал(а):

ponyol писал(а): ЗЫ. Но все же, ради любопытства, почему же мой запрос так тормозит?

Потому что его попросил ограничить выборку датами, а потом для каждой записи этой выборки сделать подзапрос и большую часть из неё выкинуть, вместо того, чтобы наложить все ограничения сразу.

Дело в том, что выборка по датам дает всего лишь 3800 записей. Т.е. сервер из этого количества выберает 800 записей и чуть ли не умирает (99% проца и бесконечное время)? Питон с такой задачей (скриптом из десятка строк) справляется ну очень быстро (не засекал)! У меня есть ощущение, что fb сначала пытается выгрибать записи по всей таблице из подзапроса, а потом по датам. По другому эту тормознутось я объяснить не могу.

От упэртый, як хохол Если бы так, то было бы как раз быстрее. А ты его заставил ограничить по дате, а потом 3800 раз

ponyol писал(а): выгрибать записи по всей таблице из подзапроса

ponyol писал(а):

dimitr писал(а):а зачем тебе DISTINCT в подзапросе?

Чтобы выбранные телефонные номера не повторялись , т.е. чтобы внешний запрос не напрягался сильно.

ЗЫ. Если внешний запрос запустиь без подзапроса, то получается около 4500 записей. Неужели fb в них так долго ищет "b.fone in"? Или я ничего не понимаю?

Не понимаеш. FB выполняет подзапрос каждый раз для проверки in. Что приводит к 4500 раз выполнению подзапроса.

eugeney писал(а): Не понимаеш. FB выполняет подзапрос каждый раз для проверки in. Что приводит к 4500 раз выполнению подзапроса.

Так бы сразу и сказали . Теперь понимаю. Я, несмышленышь, думал, что in выполняется только один раз (а почему бы не один?) и висит где нить в кеше. Странно, что не так .

ponyol писал(а): а почему бы не один?
Странно, что не так .

Не все так просто. Изза наличия selectable procedure запросы получаються не реентабелные. Т.е. ты можеш выполнить запрос

select ... from table1 join sp1(table1.field2) on 1=1
Вот и получается что sp1 будет вызванна по количеству записей в таблице.
Тоже самое и по процедурам.

ponyol писал(а):Я, несмышленышь, думал, что in выполняется только один раз (а почему бы не один?) и висит где нить в кеше. Странно, что не так .

Подзапрос сервер превращает в коррелированный, с зависимостью от внешнего через b.fone. Но ты серверу всю бодягу испортил своими условиями отбора и DISTINCT-ом сверху, который просто блокирует возможный индексный поиск по fone.

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