ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Какой вариант и когда оптимальней?
25 сообщений из 25, страница 1 из 1
Какой вариант и когда оптимальней?
    #39367514
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Вопрос к тем, кто уже испытывал производительность подобных вариантов.
Имеем два варианта инициализации переменных в ХП:
1.
Код: plsql
1.
2.
3.
4.
var1 = inp1;
var2 = inp2;
...
var<N+1> = inp<N+1>;


2.
Код: plsql
1.
2.
3.
SELECT inp1, inp2, ... inp<N+1>
  FROM RDB$DATABASE
  INTO: var1, var2, ... var<N+1>;


Возможно ли, что при количестве полей больше какого-то значения, интерпретируя BLR сервер выполнит вариант2 быстрее, чем варианта1? Если такое возможно, то каким должно быть количество полей?
...
Рейтинг: 0 / 0
15.12.2016, 12:04
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39367516
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
rdb_dev,

первый. Что за глупость rdb$database для инициализации использовать? Даже если при каких-то условиях второй окажется эффективней, то это будет экономия на спичках. Код при большом числе N во втором варианте воспринимать гораздо сложнее
...
Рейтинг: 0 / 0
15.12.2016, 12:06
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39367522
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Симонов ДенисЧто за глупость rdb$database для инициализации использовать?Я спрашиваю, а не утверждаю, ты же сразу - "глупость". К примеру, эту конструкцию разработчик может использовать, чтобы не нагружать визуальное восприятие исходного текста конструкцией BEGIN ... END.
...
Рейтинг: 0 / 0
15.12.2016, 12:17
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39367524
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
rdb_dev,

второй вариант - дурь какая-то. Право на существование имеет, а вот права на использование - нет.
...
Рейтинг: 0 / 0
15.12.2016, 12:17
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39367526
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
rdb_dev,

а зачем ему обрамлять инициализацию переменных при помощи begin/end?
...
Рейтинг: 0 / 0
15.12.2016, 12:18
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39367584
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
kdvа зачем ему обрамлять инициализацию переменных при помощи begin/end?Зависит от того, используется ли ветвление при инициализации переменных.
...
Рейтинг: 0 / 0
15.12.2016, 12:58
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39367586
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
kdvвторой вариант - дурь какая-то. Право на существование имеет, а вот права на использование - нет.На "нет" и суда нет...

Всем спасибо за высказанные мнения!
...
Рейтинг: 0 / 0
15.12.2016, 12:59
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39367653
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
rdb_dev,

если по существу, то обращение к rdb$database даст 2 чтения страниц, с диска или из кэша. Так что в цикле такая операция будет сильно медленнее, чем без нее. Если не в цикле, то чтение этих двух страниц может привести к выпадению из кэша (если кэш заполнен) других двух страниц, которые будут более важны, чем rdb$database. Так что тоже косвенно повлияет на производительность.

По моему опыту инициализация переменных, или получение значений системных переменных или функций через rdb$database в PSQL - это результат плохого понимания, зачем и почему вообще кто-либо пишет, например
select myfuction(value) from rdb$database.
Дальше, этот же код втыкается в PSQL, не раздумывая
Код: sql
1.
2.
select myfuction(value) from rdb$database
into :variable;


вместо нормального
Код: sql
1.
variable=myfunction(value);
...
Рейтинг: 0 / 0
15.12.2016, 13:30
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39367706
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
kdv, за разъяснение отдельное спасибо!

Помнится в MSSQL указание таблицы в предложении "SELECT" - необязательный элемент. Видимо, по этой же причине.
Появился попутный, чисто теоретический вопрос - как сильно, в данном случае, меняет ситуацию использование пустой временной таблицы в "FROM"?
...
Рейтинг: 0 / 0
15.12.2016, 14:01
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39367709
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
rdb_dev,

какой ещё на фиг пустой таблицы. Если ты из пустой таблицы SELECT сделать, то твои переменные не инициализируются.
...
Рейтинг: 0 / 0
15.12.2016, 14:04
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39367717
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WildSery
Участник
Симонов Денис,

Он, видимо, подразумевал подобие DUAL с 1 записью в ней, просто сформулировать не смог.
...
Рейтинг: 0 / 0
15.12.2016, 14:09
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39367722
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
WildSery, просто затупил. :)
...
Рейтинг: 0 / 0
15.12.2016, 14:11
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39367725
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WildSery
Участник
Симонов Денис,

Кстати, нет никаких препятствий, чтобы получать из пустой таблицы какие-то константные значения.
Код: sql
1.
2.
select count(*), 1 n1, 2 n2
  from emptyTable
...
Рейтинг: 0 / 0
15.12.2016, 14:12
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39367726
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
rdb_dev,

RDB$DATABASE в Firebird это не то же самое что Dual в Оракл. У нас RDB$DATABASE это настоящая таблица содержащая 1 запись, а не некая виртуальная заглушка.

Обсуждение по поводу SELECT без FROM тут уже было. Отвергнуто так как не по стандарту.

В принципе в стандарте есть такая вещь как ROW VALUE CONSTRUCTOR, которая может использоваться в качестве Derived Table.

Что-то типа такого

Код: sql
1.
SELECT T.a, T.b FROM (VALUES (1, 2), (3, 4)) T(a, b)



или даже вообще вот так

Код: sql
1.
VALUES (1, 2), (3, 4)



в трекере это есть, но когда до этого руки дойдут неизвестно. Не самая приоритетная фича.
...
Рейтинг: 0 / 0
15.12.2016, 14:12
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39367741
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Симонов ДенисВ принципе в стандарте есть такая вещь как ROW VALUE CONSTRUCTOR, которая может использоваться в качестве Derived Table.Вопрос, конечно, не в том, что будет, а в том как быть с тем, что есть, но оффтоп интересный.
Периодически мечтаю о наличии в SQL сервере возможности создания динамического ROW SET'а с возможностью передачи его не только в конструкции внутри ХП, но и в качестве параметра между процедурами. ИМХО, очень бы пригодилась.
...
Рейтинг: 0 / 0
15.12.2016, 14:25
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39367977
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Hello, Wildsery!
You wrote on 15 декабря 2016 г. 16:55:01:

Wildsery> Он, видимо, подразумевал подобие DUAL с 1 записью в нейв Оракле раньше за смешивание контекстов отстреливали ноги.
по самые уши.
но с приходом в профессию неисчислимых полчищ школоты и леммингов, всем уже начхать.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
15.12.2016, 16:57
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39368240
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Мимопроходящий, где ты разглядел смешение контекста?
...
Рейтинг: 0 / 0
16.12.2016, 02:12
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39368299
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
rdb_dev,

ты про Оракл что-нибудь знаешь?
...
Рейтинг: 0 / 0
16.12.2016, 09:22
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39368320
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Симонов Денис, еще не имел удовольствия, но планирую ознакомиться. Пока что "глаза не добежали" даже почитать EULA.
...
Рейтинг: 0 / 0
16.12.2016, 09:51
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39368322
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
rdb_dev,

ну вот когда с Ораклом познакомишься, тогда и узнаешь что такое смешивание контекстов.
...
Рейтинг: 0 / 0
16.12.2016, 09:54
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39368335
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Симонов Денис, хотя бы контекстов чего?
...
Рейтинг: 0 / 0
16.12.2016, 10:09
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39368353
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
rdb_dev,

Тома Кайта почитай. Только правильно эта тема называется переключение контекстов.

В Оракл pl/sql и sql код выполняют разные движки и соответственно возникают переключения контекста при переходе от одного кода к другому. Само по себе переключение контекста — это очень быстрая операция. По сравнению с выполнением sql-оператора — копейки. Т.е. выполнять для sql-запроса одно дополнительное переключение контекста ничего не стоит.
Проблемой становится когда переключение контекста выполняется для каждого фетча в запросе или в цикле. Т.е. если запрос возвращает 100 млн строк, то будет 200 млн. переключений контекста ( туда-сюда), а это уже совсем другое дело. У них там для этого целые рецепты по оптимизации есть.


З.Ы. В Firebird никакого переключение контекста не происходит, т.к. вся ХП вместе запросами выполняется как единый BLR.
...
Рейтинг: 0 / 0
16.12.2016, 10:22
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39368357
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Симонов Денис, в общих чертах понятно, спасибо! Но, почему-то, желания знакомиться с Oracle DB не прибавилось.
...
Рейтинг: 0 / 0
16.12.2016, 10:27
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39368368
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
rdb_dev,

так я вроде и не агитирую. Это ты тут подверг сомнению слова МП о контекстах, ничего не зная об Oracle. Пришлось вмешаться.
...
Рейтинг: 0 / 0
16.12.2016, 10:39
| Ответить | Цитировать | Написать  
Какой вариант и когда оптимальней?
    #39368372
rdb_dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rdb_dev
Участник
Симонов Денис, я не "догнал", что он имел в виду OracleDB.
...
Рейтинг: 0 / 0
16.12.2016, 10:41
| Ответить | Цитировать | Написать  
25 сообщений из 25, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Какой вариант и когда оптимальней?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&fpage=50&tid=1561799]:
 0ms
get settings:
 8ms
get forum list:
 16ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 34ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 60ms
get tp. blocked users:
 2ms
others: 268ms
total:  412ms
созд. / загр.: 412ms
x
x
Закрыть


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