ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Оптимизация запроса
17 сообщений из 42, страница 2 из 2
  2  все
Оптимизация запроса
    #38423720
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
afgm,

не вижу большой разницы. Что в первом, что во втором случае результат непредсказуем.
...
Рейтинг: 0 / 0
10.10.2013, 23:04:41
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #38423731
afgm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
afgm
Участник
Симонов Денисне вижу большой разницы. Что в первом, что во втором случае результат непредсказуем.
Согласен. Но не это беда, а многократный вызов тяжёлой процедуры.
...
Рейтинг: 0 / 0
10.10.2013, 23:18:23
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #38423926
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
afgm,

Если это требуется по смыслу то почему бы и нет. Соединение с огромных таблиц без индексов тоже плохо, но это не значит что это надо запретить.
...
Рейтинг: 0 / 0
11.10.2013, 08:32:51
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #38423950
Fly`
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Fly`
Гость
Симонов Денис, Спасибо за запрос. То что надо!

DragGET_SHIFT_PERSON всегда дает одну запись?
Да, всегда одна запись.

Участникам спасибо за дискуссию. Приоткрыли глаза! ;-)
...
Рейтинг: 0 / 0
11.10.2013, 09:03:29
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #38423964
afgm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
afgm
Участник
Симонов Денис, я и не говорю про соединение больших таблиц. Речь о том, что, возможно (очень ИМХО), есть смысл "кешировать" результаты выборки процедуры.
...
Рейтинг: 0 / 0
11.10.2013, 09:14:00
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #38423984
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
afgm,

я тут недавно спрашивал у ДЕ по этой теме и он мне ответил что это если и будет то нескоро (а может быть и совсем). Вот для PSQL функций в FB3 можно указать, что она детерминированная и тогда она не будет перевычисляться при каждом вызове если параметры совпадают. Но функции возвращают только скалярные значения.
Кстати с появлением PSQL функций надо бы подумать над тем чтобы запрещать создание индексов по выражениям для не детерминированных функций.
...
Рейтинг: 0 / 0
11.10.2013, 09:32:10
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #38424007
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Симонов Денися тут недавно спрашивал у ДЕ по этой теме и он мне ответил что это если и будет то нескоро
кешировать результат ХП в случае тяжелого джойна (при многократном вызове оной ХП и ее независимости от других потоков) - можно и это будет делаться в ряде случаев. Но не более того.

Симонов ДенисКстати с появлением PSQL функций надо бы подумать над тем чтобы запрещать создание индексов по выражениям для не детерминированных функций.
никто не мешает тебе в 2.х создавать индексы по random или по current_timestamp или по gen_uuid. Не вижу разницы с недетерминированными PSQL-функциями. Если ССЗБ - ради бога, используй.
...
Рейтинг: 0 / 0
11.10.2013, 09:45:32
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #38424037
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
dimitrкешировать результат ХП в случае тяжелого джойна (при многократном вызове оной ХП и ее независимости от других потоков) - можно и это будет делаться в ряде случаев. Но не более того.


Это хорошая новость.

dimitrникто не мешает тебе в 2.х создавать индексы по random или по current_timestamp или по gen_uuid. Не вижу разницы с недетерминированными PSQL-функциями. Если ССЗБ - ради бога, используй.

Это ничем плохим по мимо непредсказуемого результата выборки не может аукнуться?
...
Рейтинг: 0 / 0
11.10.2013, 10:09:33
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #38424297
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
dimitr, что скажешь насчёт

Симонов Денис
Код: sql
1.
2.
3.
select *
from t join proc1(t.id) p1 on 1=1
rows 1



FB 2.5

Код: plaintext
1.
The cursor identified in the UPDATE or DELETE statement is not positioned on a row.
no current record for fetch operation.

FB 3.0 Alpha

Код: plaintext
1.
ID	B
1	11

Однако

Код: sql
1.
2.
3.
select *
from proc1(t.id) p1 join t on 1=1
rows 1



В обоих версиях

Код: plaintext
1.
2.
3.
4.
5.
Column does not belong to referenced table.
Dynamic SQL Error.
SQL error code = -206.
Column unknown.
T.ID.
At line 3, column 1.


В трекер писать или и так исправиться?
...
Рейтинг: 0 / 0
11.10.2013, 12:50:54
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #38424330
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
dimitrкешировать результат ХП в случае тяжелого джойна (при многократном вызове
оной ХП и ее независимости от других потоков) - можно и это будет делаться в ряде случаев.
Но не более того.
Т.е. использование MERGE или HASH JOIN при слиянии потока из процедуры даже не
рассматривается?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
11.10.2013, 13:00:55
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #38424746
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Симонов Денисчто скажешь насчёт
не вижу тут ошибки. Нельзя во from-кляузе ссылаться на таблицу до ее объявления.
...
Рейтинг: 0 / 0
11.10.2013, 17:05:48
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #38424748
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Dimitry SibiryakovТ.е. использование MERGE или HASH JOIN при слиянии потока из процедуры даже не
рассматривается?
оно уже сейчас работает, речь шла про многократное перечитывание потока (читай: nested loops)
...
Рейтинг: 0 / 0
11.10.2013, 17:06:48
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #38424779
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
dimitrоно уже сейчас работает, речь шла про многократное перечитывание потока
(читай: nested loops)
По-моему, если поток достаточно мал для того, чтобы его закэшировать в памяти, это
сводится к HASH JOIN. Если поток большой, закэшировать его удастся только во временный
файл, а это MERGE JOIN. Какой ещё механизм для кэширования результата ХП можно придумать в
дополнение к этим двум? То есть вопрос звучит так: при каких обстоятельствах есть смысл
для оптимизатора рассматривать применение NL к ведомому потоку из ХП?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
11.10.2013, 17:18:10
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #38425016
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Dimitry Sibiryakov,

во-первых, джойны по неравенству начисто отсекают merge/hash. Во-вторых, cartesian join и иже с ними (нет условия связи) тоже идут мимо merge/hash. В третьих, пока что merge/hash не поддерживаются для outer joins. Могу еще придумать, но лень.
...
Рейтинг: 0 / 0
11.10.2013, 23:04:51
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #38425021
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
dimitrпока что merge/hash не поддерживаются для outer joins
Опаньки... А я-то был уверен, что в тройке это уже работает...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
11.10.2013, 23:16:01
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #38428402
Анна Карасикова
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Анна Карасикова
Гость
Fly` , может мой ответ и не актуален, но не вижу смысла вообще использовать "LEFT JOIN" в оптимизации вашего запроса, можно ведь так:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
select
  GS."SHIFT",
  GS.DT,
  GSP.shift_enter,
  GSP.shift_exit,
  GSP.shift_delay,
  GSP.shift_work,
  GSP.warning
FROM GET_SHIFTS_IN_MONTH(:DATE) GS, GET_SHIFT_PERSON(:PERSON_ID, GS."SHIFT", GS.DT) GSP
where (GSP.shift_enter is not null)


Подобной конструкцией, т.е. соединение результатов двух процедур при использовании в одной параметров другой, уже пользовалась.
...
Рейтинг: 0 / 0
15.10.2013, 15:49:34
| Ответить | Цитировать | Написать  
Оптимизация запроса
    #38428430
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Hello, Анна Карасикова!
You wrote on 15 октября 2013 г. 15:59:42:

Анна Карасикова> можно ведь так
не всегда и не везде
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
15.10.2013, 16:00:25
| Ответить | Цитировать | Написать  
17 сообщений из 42, страница 2 из 2
  2  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Оптимизация запроса
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=38425016&tid=1564231]:
 0ms
get settings:
 8ms
get forum list:
 16ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 52ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 43ms
get tp. blocked users:
 1ms
others: 226ms
total:  363ms
созд. / загр.: 363ms
x
x
Закрыть


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