|
![]() |
#1 |
Участник
|
А вот тут можно подробнее, почему одинаково (пусть это уже и оффтоп)?
Вроде в случае когда у нас указан набор полей, у нас меньше количество данных передаваемых между клиентом-сервером, и поэтому работать должно быстрее? Best practicies опять же, настаивают именно на варианте "укажите в запросе конкретные нужные вам поля" |
|
![]() |
#2 |
Участник
|
Цитата:
Цитата:
А если переменную назвать не "custTable", а "с" будет быстрее? (сорри за стеб) А есть ссылка? |
|
![]() |
#3 |
Участник
|
"Попробуйте использовать список полей для выбора inventJournalTrans. Использовано только 2% размера записи."
Метка @SYS91289 используемая в SysBPCheckMemberFunction.checkUseOfFieldLists() с коментарием в коде //Less than half the bandwidth of fields are used Такая ссылка устроит? |
|
![]() |
#4 |
Участник
|
![]() Цитата:
Сообщение от Pandasama
![]() А вот тут можно подробнее, почему одинаково (пусть это уже и оффтоп)?
Вроде в случае когда у нас указан набор полей, у нас меньше количество данных передаваемых между клиентом-сервером, и поэтому работать должно быстрее? Best practicies опять же, настаивают именно на варианте "укажите в запросе конкретные нужные вам поля" Видимо вам надо в коламбус на месяцок, подтянуть основы на стажеровочке ![]() Последний раз редактировалось skuull; 01.02.2019 в 08:42. |
|
![]() |
#5 |
Модератор
|
Цитата:
Цитата:
Best practicies опять же, настаивают именно на варианте "укажите в запросе конкретные нужные вам поля
trud, в Вашем примере сделано все (малый объем данных, выборка по непокрывающему индексу, диалог в транзакции) чтобы найти хоть какой-то сценарий в котором update_recordset работает хуже. Как пища для размышлений - да, годно. Насколько в реальных условиях несколько конкурентных update_recordset, на реальных объемах данных, завернутых в правильную обработку deadlock-ов, будут быстрее или медленнее (хотя бы в T2) - вот это уже было бы гораздо интереснее. Как Вы считаете? ![]()
__________________
-ТСЯ или -ТЬСЯ ? Последний раз редактировалось Vadik; 01.02.2019 в 10:34. |
|
|
За это сообщение автора поблагодарили: skuull (5). |
![]() |
#6 |
Участник
|
Цитата:
![]() Последний раз редактировалось skuull; 01.02.2019 в 09:53. |
|
![]() |
#7 |
Moderator
|
Цитата:
1. Точно есть покрывающий индекс или есть не нужные нам BLOB поля. 2. Этот самый select выполняется в недрах какого-то очень критичного по времени участка (ну например если этот select выполняется 1M раз и из за структур данных мы не можем его в какой-то внешний while select добавить). Во всех остальных случаях указание списка полей приводит к достаточно неощутимой оптимизации, но при этом повышает вероятность очень неприятных ошибок. |
|
|
За это сообщение автора поблагодарили: AlGol (1), EVGL (3), Vadik (1), ax_mct (5). |
![]() |
#8 |
Участник
|
Цитата:
Эта дискуссия имеет смысл только в случае, когда есть потребность сделать быстрее. Если мы пишем что-то что вызывается раз в году и обрабатывает 1 строку и так будет в обозримом будущем, то вообще все равно как оно написано. Но вот топикстартеру нет, он собирается вводить новые BP. А если вы пишете продукт, который будет обрабатывать большие объёмы, то с командой людей, которые не могут писать нормальный код вы далеко не уплывете. Нельзя жертвовать скоростью в угоду возможным идиотам, так привидеться писать методы по 500 строк, потому что они по-другому не поймут, им так удобней, чтобы все под рукой. |
|
![]() |
#9 |
Moderator
|
Цитата:
Сообщение от skuull
![]() А если вы пишете продукт, который будет обрабатывать большие объёмы, то с командой людей, которые не могут писать нормальный код вы далеко не уплывете. Нельзя жертвовать скоростью в угоду возможным идиотам, так привидеться писать методы по 500 строк, потому что они по-другому не поймут, им так удобней, чтобы все под рукой.
![]() Кроме того - я просто замечу, что большая часть твоих постов на форуме - это либо троллинг (неуспешный), либо - демагогия (тоже не особо удачная). Можешь, конечно, продолжать в том же духе, но похоже что более или менее активные участники уже все поняли... |
|
![]() |
#10 |
Участник
|
Цитата:
![]() |
|
![]() |
#11 |
Banned
|
Цитата:
Цитата:
Довольно непрактично оптимизировать код сразу. Это второй этап. Надежность и возможность дебага на первом этапе. А то доходит до смешного когда такой оптимизированный код приходиться расчленять чтобы видеть в дебаге почему ничего нет в этом супер-пупер навороченном select со списком полей и join. |
|
|
За это сообщение автора поблагодарили: AlGol (1). |
![]() |
#12 |
Модератор
|
Цитата:
![]()
__________________
-ТСЯ или -ТЬСЯ ? Последний раз редактировалось Vadik; 01.02.2019 в 13:17. |
|
![]() |
#13 |
Участник
|
Цитата:
По сети тоже пакет передается.. Где выигрыш то в скорости? |
|
![]() |
#14 |
Модератор
|
Цитата:
__________________
-ТСЯ или -ТЬСЯ ? |
|
![]() |
#15 |
Участник
|
Цитата:
Сообщение от Vadik
![]() trud, в Вашем примере сделано все (малый объем данных, выборка по непокрывающему индексу, диалог в транзакции) чтобы найти хоть какой-то сценарий в котором update_recordset работает хуже. Как пища для размышлений - да, годно. Насколько в реальных условиях несколько конкурентных update_recordset, на реальных объемах данных, завернутых в правильную обработку deadlock-ов, будут быстрее или медленнее (хотя бы в T2) - вот это уже было бы гораздо интереснее. Как Вы считаете?
![]() |
|