Тут палка о двух концах. С одной стороны, хорошо, когда "оно само". Но плохо, когда "оно само, но неуправляемо и по своему разумению". Иными словами, статистика созданная по выражению будет содержать статистику именно по этому выражению для этой таблицы. А вот при патче планировщика имеем эвристику.
Уже для первой линии поддержки в инструкции всегда указывал: если клиент жалуется на длительность выполнения запроса (открытия формы, построения отчёта, результатов обработки), то в первую очередь попросите его принудительно обновить статистики в БД. И только при повторении проблемы после обновления статистик следует передавать заявку на вторую линию.
Столь смелое утверждение должно сопровождаться доказательствами. Так какие RFC регламентируют локальное хранение и обработку данных? Да и вообще, какое отношение к интернету может иметь локальное хранение и обработка данных?
В аналоговом виде - фазовращателями и компараторами. То есть, на сколько градусов нужно сдвинуть фазовращателем фазу принимаемого сигнала одного приёмника, относительно другого, чтобы мгновенные уровни принимаемых сигналов совпали.
Если речь только о двух приёмниках, то по разности фаз можно определить только зону пространства, в которой находится источник, но не направление не него. В плоскости, в которой лежит прямая, на которой находятся приёмники, действительно можно определить направление. Но та же летучая мышь ловит на лету комаров в пространстве.
Уши (микрофоны) у летучих мышей направленные, направление управляемое. ФАР же как раз решает проблему направленности без изменения ориентации приемников.
команда сервиса оплаты решает изменить тип поля или удалить поле user_id и молча выкатывает обновление
Даже не рассматривая, что в реальном мире никто не будет менять тип поля или его удалять, возникает вопрос, а почему бы клиентам не пользоваться рефлексией сервера, для того, чтобы такие вещи проверять?
Зачем нужно было кувыркаться с модулем на 5В, если можно было вполне обойтись реле, диодом, полевиком и резистором? Да и реле тогда можно было бы выбрать двухполюсное.
Почему выключение нагрузки нельзя было определять напрямую датчиком тока?
Ну тут тоже, как повезёт. Помнится, как в 22.04 в момент её выхода, при установке сетевой адаптер отваливался. А уж про nomodeset не слышал только совсем ленивый линуксоид.
У меня первым дистрибутивом Linux был Gentoo. Причём совершенно осознанно, так как хотел действительно изучить Linux. И ни капли об этом не жалею.
Вот только до этого у меня был богатый опыт, начиная с генерации TKS, затем VM/SP, работа с OS/2 (не надо про её дружелюбие, когда нужен HPFS386 и LanServer), Solaris и даже немного FreeBSD. А вот неподготовленному пользователю я бы не то что Gentoo, но и Arch не стал бы рекомендовать.
Ну так тем, кому действительно необходима производительность десятичной арифметики - тем уже хорошо. А тем, кто использует x86-64, и 18 десятичных знаков покрывают большинство задач.
Проблема однако в том, что число приходится распаковывать/детостить на каждое использование.
Ну так именно тут десятичное представление и выигрывает с огромным отрывом у двоичного, когда арифметики нет или мало.
Сравните время на упаковку и распаковку символьного представления числа в BCD и bigint.
calculations on numeric values are very slow compared to the integer types
Следует заметить, что данное утверждение всегда верно для PostgreSQL, но не для DB/2 на IBM мейнфрейме или сервере на PowerPC, так как они поддерживают вычисления в десятичной арифметике аппаратно. Когда-то и x86 поддерживали, хоть и не столь эффективно. Но в x86-64 команды поддержки десятичной арифметики были удалены. Впрочем, осталась поддержка десятичной арифметики до 18 разрядов средствами FPU.
Кроме того, следует учитывать затраты на преобразование двоичных чисел в десятичные и наоборот. Особенно при интеграции. Если вычислений с десятичной точкой мало, то стоит ли конвертировать числа в десятичном представлении в двоичное и обратно?
Если речь о летучей мыши (БПЛА), то там без реального времени никак не обойтись. У меня в деревне они (живые) не только рабицу в полете "видят", но даже комаров в полёте. Причем скорость их передвижения совсем не маленькая - 10-15 м/с.
Тут палка о двух концах. С одной стороны, хорошо, когда "оно само". Но плохо, когда "оно само, но неуправляемо и по своему разумению".
Иными словами, статистика созданная по выражению будет содержать статистику именно по этому выражению для этой таблицы. А вот при патче планировщика имеем эвристику.
Тема статьи, "как научить планировщик считать его [COALESCE] селективность?". Создание статистики по COALESCE - один из ответов на этот вопрос.
Если это для Вас так важно, то изучите как формируются запросы к БД в 1С.
А разве не достаточно было создать статистику по этому COALESCE?
Уже для первой линии поддержки в инструкции всегда указывал: если клиент жалуется на длительность выполнения запроса (открытия формы, построения отчёта, результатов обработки), то в первую очередь попросите его принудительно обновить статистики в БД. И только при повторении проблемы после обновления статистик следует передавать заявку на вторую линию.
Это было бы странно, так как новому устройству, подключённому к этому же порту, питание с этого порта получить было бы невозможно.
Столь смелое утверждение должно сопровождаться доказательствами. Так какие RFC регламентируют локальное хранение и обработку данных? Да и вообще, какое отношение к интернету может иметь локальное хранение и обработка данных?
Я имел в виду, что у летучей мыши только два уха. Поэтому только на основе сдвига фаз она бы комаров на лету ловить не смогла.
Я потому и написал, что в аналоговом виде. В случае ЦАР, как в мобильной связи, ответ начинает тянуть на статью или цикл статей, а не комментарий.
В аналоговом виде - фазовращателями и компараторами. То есть, на сколько градусов нужно сдвинуть фазовращателем фазу принимаемого сигнала одного приёмника, относительно другого, чтобы мгновенные уровни принимаемых сигналов совпали.
Если речь только о двух приёмниках, то по разности фаз можно определить только зону пространства, в которой находится источник, но не направление не него. В плоскости, в которой лежит прямая, на которой находятся приёмники, действительно можно определить направление. Но та же летучая мышь ловит на лету комаров в пространстве.
Закройте глаза и не поворачивая головой попробуйте хлопком ладоней убить летящего комара не прямо перед Вами. Если сможете - то Вы уникум ))
А летучие мыши комаров в полете вообще-то ловят ртом, который куда меньше ладоней..
Эксперименты показывают, что если прямо перед собой (когда уши направлены!) человек способен определять направление с точностью 3 градуса по горизонтали, то в передней полуплоскости точность снижается до 12 градусов по горизонтали, а в задней - до 30. По вертикали же всё ещё хуже. Даже прямо перед собой точность падает до 10-15 градусов.
Очень плохо. Для более-менее точного определения направления вынуждены вертеть головой.
Уши (микрофоны) у летучих мышей направленные, направление управляемое. ФАР же как раз решает проблему направленности без изменения ориентации приемников.
Даже не рассматривая, что в реальном мире никто не будет менять тип поля или его удалять, возникает вопрос, а почему бы клиентам не пользоваться рефлексией сервера, для того, чтобы такие вещи проверять?
Зачем нужно было кувыркаться с модулем на 5В, если можно было вполне обойтись реле, диодом, полевиком и резистором? Да и реле тогда можно было бы выбрать двухполюсное.
Почему выключение нагрузки нельзя было определять напрямую датчиком тока?
Ну тут тоже, как повезёт. Помнится, как в 22.04 в момент её выхода, при установке сетевой адаптер отваливался. А уж про nomodeset не слышал только совсем ленивый линуксоид.
У меня первым дистрибутивом Linux был Gentoo. Причём совершенно осознанно, так как хотел действительно изучить Linux. И ни капли об этом не жалею.
Вот только до этого у меня был богатый опыт, начиная с генерации TKS, затем VM/SP, работа с OS/2 (не надо про её дружелюбие, когда нужен HPFS386 и LanServer), Solaris и даже немного FreeBSD. А вот неподготовленному пользователю я бы не то что Gentoo, но и Arch не стал бы рекомендовать.
Ну так тем, кому действительно необходима производительность десятичной арифметики - тем уже хорошо. А тем, кто использует x86-64, и 18 десятичных знаков покрывают большинство задач.
Ну так именно тут десятичное представление и выигрывает с огромным отрывом у двоичного, когда арифметики нет или мало.
Сравните время на упаковку и распаковку символьного представления числа в BCD и bigint.
Следует заметить, что данное утверждение всегда верно для PostgreSQL, но не для DB/2 на IBM мейнфрейме или сервере на PowerPC, так как они поддерживают вычисления в десятичной арифметике аппаратно. Когда-то и x86 поддерживали, хоть и не столь эффективно. Но в x86-64 команды поддержки десятичной арифметики были удалены. Впрочем, осталась поддержка десятичной арифметики до 18 разрядов средствами FPU.
Кроме того, следует учитывать затраты на преобразование двоичных чисел в десятичные и наоборот. Особенно при интеграции. Если вычислений с десятичной точкой мало, то стоит ли конвертировать числа в десятичном представлении в двоичное и обратно?
Если речь о летучей мыши (БПЛА), то там без реального времени никак не обойтись. У меня в деревне они (живые) не только рабицу в полете "видят", но даже комаров в полёте. Причем скорость их передвижения совсем не маленькая - 10-15 м/с.