![]() |
#21 |
Участник
|
Цитата:
Извините, что два раза спрашиваю, но уж хочется понять зачем там этот отсыл к стажёру. Последний раз редактировалось skuull; 01.02.2019 в 08:54. |
|
![]() |
#22 |
Участник
|
"Попробуйте использовать список полей для выбора inventJournalTrans. Использовано только 2% размера записи."
Метка @SYS91289 используемая в SysBPCheckMemberFunction.checkUseOfFieldLists() с коментарием в коде //Less than half the bandwidth of fields are used Такая ссылка устроит? |
|
![]() |
#23 |
Модератор
|
Цитата:
Цитата:
Best practicies опять же, настаивают именно на варианте "укажите в запросе конкретные нужные вам поля
trud, в Вашем примере сделано все (малый объем данных, выборка по непокрывающему индексу, диалог в транзакции) чтобы найти хоть какой-то сценарий в котором update_recordset работает хуже. Как пища для размышлений - да, годно. Насколько в реальных условиях несколько конкурентных update_recordset, на реальных объемах данных, завернутых в правильную обработку deadlock-ов, будут быстрее или медленнее (хотя бы в T2) - вот это уже было бы гораздо интереснее. Как Вы считаете? ![]()
__________________
-ТСЯ или -ТЬСЯ ? Последний раз редактировалось Vadik; 01.02.2019 в 10:34. |
|
|
За это сообщение автора поблагодарили: skuull (5). |
![]() |
#24 |
Участник
|
Цитата:
![]() Последний раз редактировалось skuull; 01.02.2019 в 09:53. |
|
![]() |
#25 |
Участник
|
Ну вы даете. В #1 забыли firstonly. Так что ответ #2.
|
|
![]() |
#26 |
Модератор
|
Ну давайте firstfast добавим тогда, он же тоже +3 к скорости дает
![]() ![]()
__________________
-ТСЯ или -ТЬСЯ ? Последний раз редактировалось Vadik; 01.02.2019 в 10:15. |
|
![]() |
#27 |
Участник
|
Ну, MS SQL достаточно сообразительный товарищ и знает, что по уникальному индексу можно вернуть только 1 или 0 записей. Поэтому он и без подсказки не будет рассматривать варианты оптимальной выборки множества записей.
|
|
![]() |
#28 |
Moderator
|
Насколько я понимаю, при указании firstonly еще и AOS занимается оптимизацией всяких своих внутренних буферов и сетевых обменов, поскольку он знает что второй записи не будет.
|
|
|
За это сообщение автора поблагодарили: Logger (1). |
![]() |
#29 |
Moderator
|
Цитата:
1. Точно есть покрывающий индекс или есть не нужные нам BLOB поля. 2. Этот самый select выполняется в недрах какого-то очень критичного по времени участка (ну например если этот select выполняется 1M раз и из за структур данных мы не можем его в какой-то внешний while select добавить). Во всех остальных случаях указание списка полей приводит к достаточно неощутимой оптимизации, но при этом повышает вероятность очень неприятных ошибок. |
|
|
За это сообщение автора поблагодарили: AlGol (1), EVGL (3), Vadik (1), ax_mct (5). |
![]() |
#30 |
Модератор
|
Цитата:
![]()
__________________
-ТСЯ или -ТЬСЯ ? Последний раз редактировалось Vadik; 01.02.2019 в 13:17. |
|
![]() |
#31 |
Участник
|
Цитата:
По сети тоже пакет передается.. Где выигрыш то в скорости? |
|
![]() |
#32 |
Участник
|
Цитата:
Сообщение от Vadik
![]() trud, в Вашем примере сделано все (малый объем данных, выборка по непокрывающему индексу, диалог в транзакции) чтобы найти хоть какой-то сценарий в котором update_recordset работает хуже. Как пища для размышлений - да, годно. Насколько в реальных условиях несколько конкурентных update_recordset, на реальных объемах данных, завернутых в правильную обработку deadlock-ов, будут быстрее или медленнее (хотя бы в T2) - вот это уже было бы гораздо интереснее. Как Вы считаете?
![]() |
|
![]() |
#33 |
Модератор
|
Цитата:
__________________
-ТСЯ или -ТЬСЯ ? |
|
![]() |
#34 |
Участник
|
Цитата:
Эта дискуссия имеет смысл только в случае, когда есть потребность сделать быстрее. Если мы пишем что-то что вызывается раз в году и обрабатывает 1 строку и так будет в обозримом будущем, то вообще все равно как оно написано. Но вот топикстартеру нет, он собирается вводить новые BP. А если вы пишете продукт, который будет обрабатывать большие объёмы, то с командой людей, которые не могут писать нормальный код вы далеко не уплывете. Нельзя жертвовать скоростью в угоду возможным идиотам, так привидеться писать методы по 500 строк, потому что они по-другому не поймут, им так удобней, чтобы все под рукой. |
|
![]() |
#35 |
Banned
|
Много слов ни о чем. Солидаризуюсь с fed, только обращу внимание не на ошибки, а на расширяемость кода. Если вы не используете Query или SysDa, то добавить новое поле в середину метода невозможно.
|
|
|
За это сообщение автора поблагодарили: Vadik (1). |
![]() |
#36 |
Moderator
|
Цитата:
Сообщение от skuull
![]() А если вы пишете продукт, который будет обрабатывать большие объёмы, то с командой людей, которые не могут писать нормальный код вы далеко не уплывете. Нельзя жертвовать скоростью в угоду возможным идиотам, так привидеться писать методы по 500 строк, потому что они по-другому не поймут, им так удобней, чтобы все под рукой.
![]() Кроме того - я просто замечу, что большая часть твоих постов на форуме - это либо троллинг (неуспешный), либо - демагогия (тоже не особо удачная). Можешь, конечно, продолжать в том же духе, но похоже что более или менее активные участники уже все поняли... |
|
![]() |
#37 |
Banned
|
Цитата:
Цитата:
Довольно непрактично оптимизировать код сразу. Это второй этап. Надежность и возможность дебага на первом этапе. А то доходит до смешного когда такой оптимизированный код приходиться расчленять чтобы видеть в дебаге почему ничего нет в этом супер-пупер навороченном select со списком полей и join. |
|
|
За это сообщение автора поблагодарили: AlGol (1). |
![]() |
#38 |
Участник
|
Цитата:
![]() |
|
![]() |
#39 |
Moderator
|
Я начинал во времена FIDO и там принято было всех называть на "ты". Обращение на "Вы" считалось скрытым наездом. Так что прощу извинить мою старомодность - теперь буду обращаться только на "Вы". Однако все остальное в моем высказывании - остается в силе.
Последний раз редактировалось fed; 01.02.2019 в 13:58. |
|
![]() |
#40 |
Участник
|
Цитата:
Я согласен, что список полей может вызывать ошибки чаше чем выборка всей записи. Для этого есть "Error on Invalid Field access", активно рекомендуемый МС, но это тема отдельного топика. Есть аргументы в пользу того, что он может быть медленнее чем выборка всей записи? |
|
|
За это сообщение автора поблагодарили: Vadik (1). |