Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Странное поведение оптимизатора Firebird / 25 сообщений из 45, страница 1 из 2
  1  все
16.04.2015, 10:23
    #38938003
Interloper
Interloper
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Странное поведение оптимизатора Firebird
Предположим, имеется процедура PROC1, которая изменяет данные в таблице. Тогда если выполнить запрос:
Код: sql
1.
select * from PROC1 where 0=1

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

в этом случае модификации в процедуре выглядят странно. А если процедура джойнится то в двойне странно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
16.04.2015, 15:50
    #38938419
YuRock
YuRock
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Странное поведение оптимизатора Firebird
Симонов Денисв этом случае модификации в процедуре выглядят странно
Ну, я ж и спрашиваю - почему странно?
Единственное, что плохо - 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:51
    #38938420
Мимопроходящий
Мимопроходящий
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Странное поведение оптимизатора Firebird
Hello, Yurock!
You wrote on 16 апреля 2015 г. 15:51:31:

Yurock> Ну, я ж и спрашиваю - почему странно?
потому, что трусы на голове.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Странное поведение оптимизатора Firebird / 25 сообщений из 45, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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