Страница 1 из 1
Какое ограничение по длине запроса у FireBird?
Добавлено: 19 дек 2005, 16:55
Aleksandr.
В программе из списка формируется запрос на таблицу:
Код: Выделить всё
SELECT * FROM Table WHERE (Field1 IN (x1,x2,x3) AND Field2=y1)
OR (Field1=x4 AND Field2=y2) OR ...
Таких условий в запросе оказалось дохрена и более, и FIBQuery мне сматюгнулся на Unexpected end of command. Погрешив на него, я вставил запрос в IbExpert, но тот, подумав пару минут на вклейке текста, при выполнении выдал то же самое.
Стало быть, есть какое-то ограничение на длину запроса. Только вот в сколько знаков?
И сразу же, как следствие, вопрос: будет ли быстрее такого рода запрос, по такому WHERE выбирающий процентов 50 записей, полного Fetch таблицы? Или он на отбор условий больше потратит времени?
Добавлено: 20 дек 2005, 08:25
Dimitry Sibiryakov
На длину текста ограничение 64к-1. Но есть еще ограничение оптимизатора на 255 потоков данных (насколько я понимаю "x=y or a=b" это четыре потока).
Добавлено: 20 дек 2005, 17:09
hvlad
Dimitry Sibiryakov писал(а):На длину текста ограничение 64к-1. Но есть еще ограничение оптимизатора на 255 потоков данных (насколько я понимаю "x=y or a=b" это четыре потока).
Поток - это таблица, процедура, обединение или агрегат.
А то, что ты написал - 2 boolean's
Добавлено: 21 дек 2005, 13:36
Aleksandr.
Спасибо. Вот же блин фигня... А что насчет второго вопроса? Я сделал разбивку запроса на несколько с меньшим числом условий в WHERE, и сложилось у меня впечатление, что они в сумме отработали быстрее, чем один большой. Хотя, может, это свойство FIBQuery такое...
Добавлено: 21 дек 2005, 13:51
Merlin
Это свойство запросов такое
)) Планы разные. И вообще, потребность в запросах о 64 Кб длиною вызывает смутные сомения насчёт консерватории
Добавлено: 21 дек 2005, 17:16
eugeney
Merlin писал(а):потребность в запросах о 64 Кб длиною вызывает смутные сомения насчёт консерватории
Или в атогенериловке таких запросов. Т.е. их строит автомат.
Добавлено: 21 дек 2005, 20:11
Aleksandr.
Merlin писал(а):Это свойство запросов такое
)) Планы разные. И вообще, потребность в запросах о 64 Кб длиною вызывает смутные сомения насчёт консерватории
С консерваторией просто полная беда. По tcp клиентской проге во время сеанса связи с удаленным серваком (не FireBird) приходит в бинарном формате информация об изменениях в базе. И на клиенте все эти изменения должны перевестись в запросы к таблицам. Соответственно и получаются такие наборы.
Добавлено: 22 дек 2005, 10:16
kdv
и что тебя заставляет все это втыкать в "один запрос"?
Добавлено: 23 дек 2005, 15:39
Aleksandr.
kdv писал(а):и что тебя заставляет все это втыкать в "один запрос"?
Лень
. Теперь сделал проверку и разбивку на пакеты. Не поскажете, а правдив тот слух, что деактивация индексов перед групповыми вставками/обновлениями весьма ускоряет таковые?
Добавлено: 23 дек 2005, 16:03
kdv
так попробуй. все зависит от количества индексов, и от количества дубликатов ключей в этих индексах.