Скажите, правильно я понял, что сейчас новые заметки можно создавать только через ПКМ по дереву? Мне кажется, было бы удобно создавать дочерние заметки для открытой текущей через команду и(или) кнопку на ribbon
Насколько вообще количество VLF реально влияет на производительность? Какой-то оверхед, несомненно, есть, но насколько он значим на современном железе? Может это уже как те пресловутые рекомендации о 5% и 30% для реогра\ребилда, которые тянутся из глубины веков и не сильно релевантны для реалий NVME дисков?
Если на журнал транзакций не действует Instant File Initialization, то зачем ему ставить прирост с шагом 1–4Gb? Тем более, что с MSSQL 2022 IFI распростанятеся и на лог (но только если прирост не больше 64 MB)
Ориентироваться на проценты в плане запроса это неверный подход. План компилируется до выполнения и проценты это не более чем ожидания оптимизатора. В реальности потом может быть что угодно. Например, у вас наибольшее время вполне может быть на hash match из-за неверной оценки количества строк в Cities и, как следствие, выливания всего этого на диск в tempdb. В идеале нужно смотреть время выполнения узлов в актуальном плане (так же игнорируя проценты, т.к. они не корректируются после выполнения запроса)
Про сравнение телефонов - разве bases, который core plugin из коробки, не позволяет сделать то-же самое в несколько кликов, без вот этой вот простыни кода?
А зачем вы смотрите фильмы 90х годов, когда сейчас каждый день выходят премьеры превосходящие то что выпускали в 90х?
Во-первых, это очень смелое заявление. Думаю, что многие с вами не согласятся (я в том числе). Во-вторых, первый ГП, если правильно помню, вышел где-то в начале 2000-х
Правильно я понял, что этот современный плеер - платный, с закрытым кодом, под андроид, а для установки нужно на тг-канале найти ссылку на apk на mega.nz? И под windows его предлагается запускать в эмуляторе? И вы на полном серьезе утверждаете, что он лучше сабжа?
Открыл ваш проект, дошел по 5 задачи (сортировка по title и выборка с offset) и получил стоимость выполнения на пару порядков выше, чем в рекорде. Удивившись, заглянул в рекорды, а там на первых местах вариант с 'where film_id between 21 and 30'. Пожалуй, продолжу и дальше рекомендовать sql-ex
Скажите, правильно я понял, что сейчас новые заметки можно создавать только через ПКМ по дереву? Мне кажется, было бы удобно создавать дочерние заметки для открытой текущей через команду и(или) кнопку на ribbon
Насколько вообще количество VLF реально влияет на производительность? Какой-то оверхед, несомненно, есть, но насколько он значим на современном железе? Может это уже как те пресловутые рекомендации о 5% и 30% для реогра\ребилда, которые тянутся из глубины веков и не сильно релевантны для реалий NVME дисков?
Если на журнал транзакций не действует Instant File Initialization, то зачем ему ставить прирост с шагом 1–4Gb? Тем более, что с MSSQL 2022 IFI распростанятеся и на лог (но только если прирост не больше 64 MB)
Приравнять человека, у которого в сумке или кармане лежит перочинный нож, к наркоману - это знатный передёрг.
У вас, при этом, стало в 5 раз больше свободного времени или в 5 раз больше денег платят? Или в 5 раз больше задач спускать начали?
Кубик на КДПВ крайне сомнителен по сочетанию цветов
Разве обновление статистики не приводит к рекомпиляции планов, которые её используют?
Ориентироваться на проценты в плане запроса это неверный подход. План компилируется до выполнения и проценты это не более чем ожидания оптимизатора. В реальности потом может быть что угодно. Например, у вас наибольшее время вполне может быть на hash match из-за неверной оценки количества строк в Cities и, как следствие, выливания всего этого на диск в tempdb. В идеале нужно смотреть время выполнения узлов в актуальном плане (так же игнорируя проценты, т.к. они не корректируются после выполнения запроса)
В данном случае и не надо, ссылку на фото можно тоже в yaml добавить. Наверное Datacore и мощная штука, но пример явно неудачный.
Про сравнение телефонов - разве bases, который core plugin из коробки, не позволяет сделать то-же самое в несколько кликов, без вот этой вот простыни кода?
Не очень понятно, почему вы считаете параллельные планы менее эффективным, ведь во всех случаях elapsed time у них меньше.
В каких?
Зависит от СУБД. В Sql Server поддерживается физическая сортировка, в Postgresql, емнип, нет.
Про моментальный `SELECT COUNT(*) FROM Books` вы что-то погорячились...
Тема проводов из бескислородной меди осталась не раскрыта, непорядок.
Во-первых, это очень смелое заявление. Думаю, что многие с вами не согласятся (я в том числе). Во-вторых, первый ГП, если правильно помню, вышел где-то в начале 2000-х
Правильно я понял, что этот современный плеер - платный, с закрытым кодом, под андроид, а для установки нужно на тг-канале найти ссылку на apk на mega.nz? И под windows его предлагается запускать в эмуляторе? И вы на полном серьезе утверждаете, что он лучше сабжа?
Открыл ваш проект, дошел по 5 задачи (сортировка по title и выборка с offset) и получил стоимость выполнения на пару порядков выше, чем в рекорде. Удивившись, заглянул в рекорды, а там на первых местах вариант с 'where film_id between 21 and 30'. Пожалуй, продолжу и дальше рекомендовать sql-ex
"Я могу отчитаться за каждый заработанный мной миллион, кроме первого" (с) Дж.Рокфеллер
К каждой подобной новости стоит в уме добавлять "пока что"