А зачем вы смотрите фильмы 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. "
В pro_probackup, например, вместо ненужных баз восстанавливается пустая "заглушка". Восстанавливать нужно, разумеется, не поверх боевого кластера, а куда-то рядом, а потом дамп с снимать и на бой накатывать. В Sql Server сильно проще, конечно...
Там достаточно показать два случая - есть row exclusive набор строк, а pg_dump пытается ACCESS SHARE MODE NOWAIT вангую что он тупо не сможет таблицу заблочить и бэкап будет неполным
Зачем ванговать, если можно просто попробовать? Всё нормально дампится. Вам уже сказали, что вы путаете SHARE и ACCESS SHARE, а у них разная совместимость с другими блокировками.
Третий вариант он не совсем очевиден но есть у всех СУБД есть понятие устаревание shapshot
Если пройти по ваше ссылке, то можно прочитать, что в постгресе оно отключено по умолчанию.
Поэтому в общем случает RR не гарантирует, что SELECT вернет тотже резуьтат
В общем случае нет, но в постгресе, всё же, да: PostgreSQL's Repeatable Read implementation does not allow phantom reads. This is acceptable under the SQL standard because the standard specifies which anomalies must not occur at certain isolation levels; higher guarantees are acceptable. https://www.postgresql.org/docs/current/transaction-iso.html
Не очень понятно, почему вы считаете параллельные планы менее эффективным, ведь во всех случаях 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. "
Речь про статью, где вы утверждаете, что pg_dump блокирует запись в таблицы во время своей работы?
В pro_probackup, например, вместо ненужных баз восстанавливается пустая "заглушка". Восстанавливать нужно, разумеется, не поверх боевого кластера, а куда-то рядом, а потом дамп с снимать и на бой накатывать. В Sql Server сильно проще, конечно...
Зачем ванговать, если можно просто попробовать? Всё нормально дампится. Вам уже сказали, что вы путаете SHARE и ACCESS SHARE, а у них разная совместимость с другими блокировками.
Если пройти по ваше ссылке, то можно прочитать, что в постгресе оно отключено по умолчанию.
В общем случае нет, но в постгресе, всё же, да: PostgreSQL's Repeatable Read implementation does not allow phantom reads. This is acceptable under the SQL standard because the standard specifies which anomalies must not occur at certain isolation levels; higher guarantees are acceptable. https://www.postgresql.org/docs/current/transaction-iso.html