ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Странное поведение оптимизатора Firebird
45 сообщений из 45, показаны все 2 страниц
  все  
Странное поведение оптимизатора Firebird
    #38938003
Interloper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Interloper
Участник
Предположим, имеется процедура PROC1, которая изменяет данные в таблице. Тогда если выполнить запрос:
Код: sql
1.
select * from PROC1 where 0=1

и сделать коммит после выполнения, данные изменятся. Почему оптимизатор делает выборку из процедуры, если условие where заведомо ложно? Ведь сразу понятно, что в выборке не будет строк.
Версия сервера Firebird: 1.5
...
Рейтинг: 0 / 0
16.04.2015, 10:23
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938043
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
Interloperпроцедура PROC1, которая изменяет данные в таблицеСелективная процедура меняющая данные вполне себе сравнима с "выстрелил себе в ногу"
...
Рейтинг: 0 / 0
16.04.2015, 10:58
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938044
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Interloper,

никогда не делай в селективных процедурах изменение данных. По поводу оптимизатора читай http://www.ibase.ru/devinfo/dataaccesspaths.htm
...
Рейтинг: 0 / 0
16.04.2015, 10:58
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938069
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Interloper,

"заведомая ложность" условий не проверяется оптимизатором. И закладываться на оптимизатор при изменении данных нельзя по определению. Сервер сделал ровно то, что его попросили - не вернул ни одной строки. Любые связанные эффекты - проблемы индейцев с точки зрения шерифа.
...
Рейтинг: 0 / 0
16.04.2015, 11:22
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938074
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
InterloperПочему оптимизатор делает выборку из процедуры, если условие where заведомо ложно?
потому что сначала выполняется процедура, а потом проверяется where.
...
Рейтинг: 0 / 0
16.04.2015, 11:24
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938152
Interloper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Interloper
Участник
kdvInterloperПочему оптимизатор делает выборку из процедуры, если условие where заведомо ложно?
потому что сначала выполняется процедура, а потом проверяется where.
Мне нужно сделать так, чтобы процедура не выполнялась, если условие ложно. Логичнее сначала проверить where, если его условие не зависит от выборки и ложно, то незачем пытаться выбирать данные.
...
Рейтинг: 0 / 0
16.04.2015, 12:12
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938162
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
InterloperМне нужно сделать так, чтобы процедура не выполнялась, если условие ложно.
тогда до свидания.
...
Рейтинг: 0 / 0
16.04.2015, 12:18
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938170
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
InterloperМне нужно сделать так, чтобы процедура не выполнялась, если условие
ложно.
Ну и что тебе мешает проверить условие и НЕ ВЫЗЫВАТЬ процедуру если оно ложно?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
16.04.2015, 12:25
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938173
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Interloper,

зависит от многих факторов. Это не всегда можно сделать. Надо следить за зависимостями есть ли в условиях выходные столбцы процедуры или нет. Пока оптимизатор такого не делает.
Есть обходной путь

Код: sql
1.
2.
3.
select P.*
from rdb$database
left join PROC1 P on 1=0
...
Рейтинг: 0 / 0
16.04.2015, 12:27
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938179
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
m7m
Участник
InterloperМне нужно сделать так, чтобы процедура не выполнялась, если условие ложно.
Логичнее сначала проверить where, если его условие не зависит от выборки и ложно, то незачем пытаться выбирать данные.
Ну так никто не мешает и IF поставить и не вызывать процедуру

зы. и даже если процедура не меняет данные,
такой подход может дать ощутимый выигрыш во времени выполнения
...
Рейтинг: 0 / 0
16.04.2015, 12:30
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938193
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
m7m
Участник
Симонов Денисзависит от многих факторов. Это не всегда можно сделать. Надо следить за зависимостями есть ли в условиях выходные столбцы процедуры или нет. Пока оптимизатор такого не делает.


Надеюсь, что и не будет такого делать
Ибо не надо писать такой код (Сугубо моё мнение).
...
Рейтинг: 0 / 0
16.04.2015, 12:40
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938202
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
InterloperМне нужно сделать так, чтобы процедура не выполнялась, если условие ложно.Передай это условие, как входной параметр процедуры и внутри проанализируй.
...
Рейтинг: 0 / 0
16.04.2015, 12:46
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938214
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Interloper,

покажи текст процедуры. Чувствую с изменениями данных внутри неё ты нарвёшся на грабли даже когда этого условия нет.
...
Рейтинг: 0 / 0
16.04.2015, 12:53
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938328
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
Симонов Денисникогда не делай в селективных процедурах изменение данных. По поводу оптимизатора читай http://www.ibase.ru/devinfo/dataaccesspaths.htm
А можно разъяснить поподробнее или тынцнуть, почему так? Только потому, что, предполагается вызов селекта из ридонли транзакции? Иногда очень удобно создавать некий кэш данных в селективной процедуре. Можно, конечно, его создавать и после вызова процедуры - вызовом другой процедуры, но неудобно/некрасиво.
...
Рейтинг: 0 / 0
16.04.2015, 14:30
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938356
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
YuRockА можно разъяснить поподробнее или тынцнуть, почему так?
скажем, в обновлении данных в селективных процедурах есть специфика. Об этом написано в
http://www.ibase.ru/devinfo/sp_call.htm

то есть, если обновление данных стоит в цикле с suspend, то не факт, что такое обновление дойдет до конца. Потому что suspend выполняется при fetch, а пользователь совершенно необязательно считает всю выборку к себе. То есть, до EOF он не дойдет, а значит не все обновления выполнятся.

В результате такую процедуру для гарантированного выполнения на всех записях придется обрамлять в запрос типа select count(*) from procedure, что нивелирует suspend.

YuRockИногда очень удобно создавать некий кэш данных в селективной процедуре.
я не знаю, о чем речь, потому что никакого "кэша" при выборке из процедуры не будет, то есть, после вывода из процедуры все результаты "улетят в пространство". Автор ОБНОВЛЯЕТ ДАННЫЕ в селективной процедуре. Отсюда и проблемы.
...
Рейтинг: 0 / 0
16.04.2015, 14:58
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938360
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
kdv,

Спасибо, понятно. Про suspend->fetch я знал. Это единственный "подводный камень"? Для "моего" случая это не проблема.

Я использую изменения данных в селективной процедуре в след. случае: есть таблица - "КэшОстатковТоваровНаСмену". Процедура проверяет, есть ли на эту "смену" запись, если есть - сразу возвращает значение из этой записи (SUSPEND), если нет - считает остатки товаров (на основе предыдущих записей в "кэше" и других данных), добавляет запись в "КэшОстатковТоваровНаСмену" и делает SUSPEND. В этом случае ничего страшного не произойдет, если не все фетчи "сделаются".
...
Рейтинг: 0 / 0
16.04.2015, 15:07
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938363
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
YuRock,

потому что есть такой волшебный оператор как SUSPEND почитай как он работает.

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
CREATE PROCEDURE P 
RETURNS (ID int)
AS
BEGIN
  FOR SELECT ID FROM T 
        INTO :ID
  DO BEGIN
     DELETE FROM T2 WHERE ID_T = :ID;
     SUSPEND; 
  END
END

SELECT * FROM P



В таблице T 1000000 записей. Сколько раз удаление будет сделано? Учти что набор данных может быть недофетчен.
И как сказал dimitr никогда не надо делать никаких предположений о работе оптимизатора. JOIN с такой процедурой может дать вообще непредсказуемые результаты.

Я вижу только одно исключение в данном случае это вставка во временные таблицы. Но там тоже надо действовать осторожно. Как минимум не делать ничего того что может модифицировать данные в курсоре в котором есть SUSPEND
...
Рейтинг: 0 / 0
16.04.2015, 15:07
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938368
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
YuRock,

про SUSPEND есть ещё один прикол. В тройке исправили нестабильный PSQL курсор. Так вот это работает только если в этом курсоре нет SUSPEND.
...
Рейтинг: 0 / 0
16.04.2015, 15:10
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938372
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
Симонов ДенисЯ вижу только одно исключение в данном случае это вставка во временные таблицы
Спасибо, мой случай другой: 17524639 - мне кажется такое тоже имеет право на жизнь.
А изменять важные данные и делать suspend в цикле FOR SELECT у меня ума еще не хватало пока
...
Рейтинг: 0 / 0
16.04.2015, 15:14
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938384
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
YuRock,

при осторожном использовании в принципе можно. Но проще взять за правило если в процедуре есть модификации и надо вернуть 1 строку, то использовать вызов EXECUTE PROCEDURE без SUSPEND в процедуре.
...
Рейтинг: 0 / 0
16.04.2015, 15:21
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938389
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
Симонов ДенисВ тройке исправили нестабильный PSQL курсор.
Спасибо, я такой проблемы старался избегать всегда. А SUSPEND в процедурах, которые что-то меняют, я делаю только в случаях, как вышеописанный. Т.е. никогда не меняя данные курсора.
...
Рейтинг: 0 / 0
16.04.2015, 15:24
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938393
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
Симонов ДенисНо проще взять за правило если в процедуре есть модификации и надо вернуть 1 строку, то использовать вызов EXECUTE PROCEDURE без SUSPEND в процедуре
Ну, понятно, если 1 строку, то лучше без SUSPEND. Но бывает, что надо по списку товаров отчет показать, например. А иногда джойнить удобно - при этом вообще без SUSPEND не обойтись.
...
Рейтинг: 0 / 0
16.04.2015, 15:31
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938403
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
YuRock,

в этом случае модификации в процедуре выглядят странно. А если процедура джойнится то в двойне странно.
...
Рейтинг: 0 / 0
16.04.2015, 15:39
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938419
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
Симонов Денисв этом случае модификации в процедуре выглядят странно
Ну, я ж и спрашиваю - почему странно?
Единственное, что плохо - read/write транзакция может сравнительно долго висеть, пока отчет открыт (если не все записи профетчились, у меня все фетчатся и сразу коммит).
А джойн - используется в случае, когда одну строку возвращает. Например, для проверки параметров товаров перед продажей. Что-то типа
Код: sql
1.
2.
3.
4.
5.
6.
SELECT
  A.PRICE,
  R.REST
FROM ARTICLES A
     LEFT JOIN GET_REST( A.ARTICLE_ID ) G ON 1=1
WHERE A.ARTICLE_ID = 12345


Можно join, можно подзапрос - тут непринципиально важно - 1 запись будет. А если в GET_REST передать NULL - то будет отчет по всем товарам (остатки).
...
Рейтинг: 0 / 0
16.04.2015, 15:50
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938420
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Hello, Yurock!
You wrote on 16 апреля 2015 г. 15:51:31:

Yurock> Ну, я ж и спрашиваю - почему странно?
потому, что трусы на голове.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
16.04.2015, 15:51
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938425
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
Мимопроходящийпотому, что трусы на голове.
Это последний аргумент?
...
Рейтинг: 0 / 0
16.04.2015, 15:55
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938461
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
YuRock,

потому что ты не можешь предсказать сколько раз у тебя модификация данных в процедуре произойдёт. 1 раз, 100 или 0.
...
Рейтинг: 0 / 0
16.04.2015, 16:42
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938468
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
Симонов Дениспотому что ты не можешь предсказать сколько раз у тебя модификация данных в процедуре произойдёт. 1 раз, 100 или 0.
А зачем мне это предсказывать, если мне это вообще не важно?
...
Рейтинг: 0 / 0
16.04.2015, 16:47
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938470
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
Симонов Денис,

Что странного в том, что я не могу предсказать то, что непредсказуемо?
...
Рейтинг: 0 / 0
16.04.2015, 16:48
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938474
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
YuRock,

странно желание что-то модифицировать при выборке. Если нужна модификация запускают отдельный запрос на модификацию.
...
Рейтинг: 0 / 0
16.04.2015, 16:55
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938477
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
Симонов Денисстранно желание что-то модифицировать при выборке
Сервер, ОС, ... модифицируют свой кэш "при выборке". Это Вам почему-то не кажется странным.
...
Рейтинг: 0 / 0
16.04.2015, 17:01
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938480
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Симонов Денисстранно желание что-то модифицировать при выборке.
Да ладно, materialized view refresh on demand не такая уж и странная вещь.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
16.04.2015, 17:02
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938491
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Dimitry Sibiryakov,

дык они же модифицируется не во время того как из них select делается.
...
Рейтинг: 0 / 0
16.04.2015, 17:10
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938499
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Симонов Денисдык они же модифицируется не во время того как из них select
делается
Нет, как раз в это время они и модифицируются. В отличии от refresh on commit собратьев.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
16.04.2015, 17:13
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938508
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Dimitry Sibiryakov,

хм... Я почитал про них. Написано что изменения в этом режиме вносятся по расписанию.
...
Рейтинг: 0 / 0
16.04.2015, 17:19
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38938551
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Симонов ДенисЯ почитал про них.
Хммм... Надо тоже пойти почитать. Вдруг Оракул ещё глупее чем я думал?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
16.04.2015, 17:48
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38939035
Interloper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Interloper
Участник
m7mInterloperМне нужно сделать так, чтобы процедура не выполнялась, если условие ложно.
Логичнее сначала проверить where, если его условие не зависит от выборки и ложно, то незачем пытаться выбирать данные.
Ну так никто не мешает и IF поставить и не вызывать процедуру

зы. и даже если процедура не меняет данные,
такой подход может дать ощутимый выигрыш во времени выполнения
Мешает. Мне нужно составить запрос SELECT, в который подставляется некий параметр в условие WHERE. Сам запрос менять нельзя. Поэтому нужно, чтобы процедура не вызывалась, если параметр = false.
...
Рейтинг: 0 / 0
17.04.2015, 12:15
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38939052
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
InterloperМне нужно составить запрос SELECT... Сам запрос менять нельзя

EXECUTE BLOCK даст тебе такой "запрос SELECT", в который можно вставить IF
...
Рейтинг: 0 / 0
17.04.2015, 12:26
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38939072
Interloper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Interloper
Участник
YuRockInterloperМне нужно составить запрос SELECT... Сам запрос менять нельзя

EXECUTE BLOCK даст тебе такой "запрос SELECT", в который можно вставить IF
У нас FB 1.5.
...
Рейтинг: 0 / 0
17.04.2015, 12:35
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38939095
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Interloper,

я же тебе дал вариант с LEFT JOIN
...
Рейтинг: 0 / 0
17.04.2015, 12:46
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38939215
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
Симонов Денися же тебе дал вариант с LEFT JOIN
Из "Сам запрос менять нельзя" я понял, что процедуру ему менять нельзя. А с JOIN она всё равно вызовется.
InterloperУ нас FB 1.5.
Тогда сделай еще одну процедуру, в которую уже передавай параметр, в ней же делай IF
...
Рейтинг: 0 / 0
17.04.2015, 13:55
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38939222
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
YuRockСимонов Денися же тебе дал вариант с LEFT JOIN
Из "Сам запрос менять нельзя" я понял, что процедуру ему менять нельзя. А с JOIN она всё равно вызовется.


не вызовется. Можешь проверить.
...
Рейтинг: 0 / 0
17.04.2015, 13:59
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38939231
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
Симонов Денисне вызовется. Можешь проверить.
on 1=0 не заметил. Чес. говоря не могу вкурить, как такое можно использовать.
...
Рейтинг: 0 / 0
17.04.2015, 14:02
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38939253
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
YuRock,

ну например вот так

Код: sql
1.
2.
3.
select P.*
from rdb$database
left join PROC1 P on :flag=1



но это верно только для LEFT JOIN
...
Рейтинг: 0 / 0
17.04.2015, 14:15
| Ответить | Цитировать | Написать  
Странное поведение оптимизатора Firebird
    #38939405
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
Симонов Денис, ясно. Сегодня не мой день вообще.
...
Рейтинг: 0 / 0
17.04.2015, 15:47
| Ответить | Цитировать | Написать  
45 сообщений из 45, показаны все 2 страниц
  все  
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Странное поведение оптимизатора Firebird
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]