Какое ограничение по длине запроса у FireBird?

Запросы, планы, оптимизация запросов, ...

Модераторы: kdv, CyberMax

Ответить
Aleksandr.
Сообщения: 63
Зарегистрирован: 18 май 2005, 19:13

Какое ограничение по длине запроса у FireBird?

Сообщение Aleksandr. » 19 дек 2005, 16:55

В программе из списка формируется запрос на таблицу:

Код: Выделить всё

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 таблицы? Или он на отбор условий больше потратит времени?

Dimitry Sibiryakov
Заслуженный разработчик
Сообщения: 1436
Зарегистрирован: 15 сен 2005, 09:05

Сообщение Dimitry Sibiryakov » 20 дек 2005, 08:25

На длину текста ограничение 64к-1. Но есть еще ограничение оптимизатора на 255 потоков данных (насколько я понимаю "x=y or a=b" это четыре потока).

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 20 дек 2005, 17:09

Dimitry Sibiryakov писал(а):На длину текста ограничение 64к-1. Но есть еще ограничение оптимизатора на 255 потоков данных (насколько я понимаю "x=y or a=b" это четыре потока).
Поток - это таблица, процедура, обединение или агрегат.
А то, что ты написал - 2 boolean's :wink:

Aleksandr.
Сообщения: 63
Зарегистрирован: 18 май 2005, 19:13

Сообщение Aleksandr. » 21 дек 2005, 13:36

Спасибо. Вот же блин фигня... А что насчет второго вопроса? Я сделал разбивку запроса на несколько с меньшим числом условий в WHERE, и сложилось у меня впечатление, что они в сумме отработали быстрее, чем один большой. Хотя, может, это свойство FIBQuery такое...

Merlin
Динозавр IB/FB
Сообщения: 1502
Зарегистрирован: 27 окт 2004, 11:44

Сообщение Merlin » 21 дек 2005, 13:51

Это свойство запросов такое :))) Планы разные. И вообще, потребность в запросах о 64 Кб длиною вызывает смутные сомения насчёт консерватории ;)

eugeney
Сообщения: 79
Зарегистрирован: 29 окт 2004, 18:51

Сообщение eugeney » 21 дек 2005, 17:16

Merlin писал(а):потребность в запросах о 64 Кб длиною вызывает смутные сомения насчёт консерватории ;)
Или в атогенериловке таких запросов. Т.е. их строит автомат.

Aleksandr.
Сообщения: 63
Зарегистрирован: 18 май 2005, 19:13

Сообщение Aleksandr. » 21 дек 2005, 20:11

Merlin писал(а):Это свойство запросов такое :))) Планы разные. И вообще, потребность в запросах о 64 Кб длиною вызывает смутные сомения насчёт консерватории ;)
С консерваторией просто полная беда. По tcp клиентской проге во время сеанса связи с удаленным серваком (не FireBird) приходит в бинарном формате информация об изменениях в базе. И на клиенте все эти изменения должны перевестись в запросы к таблицам. Соответственно и получаются такие наборы.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 22 дек 2005, 10:16

и что тебя заставляет все это втыкать в "один запрос"?

Aleksandr.
Сообщения: 63
Зарегистрирован: 18 май 2005, 19:13

Сообщение Aleksandr. » 23 дек 2005, 15:39

kdv писал(а):и что тебя заставляет все это втыкать в "один запрос"?
Лень :oops: . Теперь сделал проверку и разбивку на пакеты. Не поскажете, а правдив тот слух, что деактивация индексов перед групповыми вставками/обновлениями весьма ускоряет таковые?

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 23 дек 2005, 16:03

так попробуй. все зависит от количества индексов, и от количества дубликатов ключей в этих индексах.

Ответить