Ориентироваться на проценты в плане запроса это неверный подход. План компилируется до выполнения и проценты это не более чем ожидания оптимизатора. В реальности потом может быть что угодно. Например, у вас наибольшее время вполне может быть на 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
Кстати, MSSQL с его огромным плоским buffer cache это очень неудобная аппликация как для L3 cache, так и для NUMA - нет привязки тредов к месту памяти, они могут рандомно читать отовсюду.
Погодите, в документации пишут, что "The buffer manager is non-uniform memory access (NUMA) aware. Buffer cache pages are distributed across hardware NUMA nodes, which allows a thread to access a buffer page that is allocated on the local NUMA node rather than from foreign memory."
Прямой вопрос - есть ли всетаки в Постргесе аналог верификации бэкапа? Например в MS SQL online бэкап идет на уровне страниц, и Verify backup соответственно по ним контрольные суммы проверяет.
Емнип, pg_basebackup по умолчанию проверяет контрольные суммы (разумеется, если они были предварительно включены)
Не помните, что писали в собственной статье? Пожалуйста: "С точки зрения целостности все хорошо – используется уровень изоляции SET TRANSACTION ISOLATION LEVEL REPEATABLE READ. Он достаточно жесткий, т.е. работа параллельных процессов на запись во время длительного бэкапа будет парализована. Каждая таблица блокируется полностью до окончания команд COPY. "
Разве обновление статистики не приводит к рекомпиляции планов, которые её используют?
Ориентироваться на проценты в плане запроса это неверный подход. План компилируется до выполнения и проценты это не более чем ожидания оптимизатора. В реальности потом может быть что угодно. Например, у вас наибольшее время вполне может быть на 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
"Я могу отчитаться за каждый заработанный мной миллион, кроме первого" (с) Дж.Рокфеллер
К каждой подобной новости стоит в уме добавлять "пока что"
Обновление статистики так же каждую ночь делали?
А исходная проблема-то разрешилась? Т.е. обновление статистики не помогало, а теперь всё летает?
Пропал калабуховский дом.
Погодите, в документации пишут, что "The buffer manager is non-uniform memory access (NUMA) aware. Buffer cache pages are distributed across hardware NUMA nodes, which allows a thread to access a buffer page that is allocated on the local NUMA node rather than from foreign memory."
Емнип, pg_basebackup по умолчанию проверяет контрольные суммы (разумеется, если они были предварительно включены)
Не помните, что писали в собственной статье? Пожалуйста: "С точки зрения целостности все хорошо – используется уровень изоляции SET TRANSACTION ISOLATION LEVEL REPEATABLE READ. Он достаточно жесткий, т.е. работа параллельных процессов на запись во время длительного бэкапа будет парализована. Каждая таблица блокируется полностью до окончания команд COPY. "