У меня ощущение, что вы не очень разобрались в ситуации. Позвольте привести аргументы, расходящиеся с вашим мнением...
Всерьез, обстоятельно, по делу отвечаете. Но при этом вам разве совершенно очевидно, что это просто очередной ботик, отрабатывающий свою 30-сребренниковую пайку, причем из наших же налогов? Вопрос не риторический.
Спасибо большое, такое альтернативное мнение всегда важно знать
Серьезно? Вы статью-то читали? Автор в Мюнхене никогда даже и не был, столько бреда не написал бы и однодневный турист. В реальности же на 3/4 дикое вранье из каких-то затхлых методичек.
Так для этого и нужно читать оценочные мощности ветвей в плане: для пустого xml (при optimize for(xml=null)) оптимизатор предполагает пустой результат разбора, но поскольку нулевые оценочные мощности он никогда не ставит — оценочная мощность этой подветви будет равна одной строке. Соответственно, может меняться и остальной план из этой оценки, вот и вся магия.
Для новичка, который притянул сюда не имеющую отношение к происходящему эскалацию блокировок только потому, что еще вчера не знал даже, что это такое, откуда берется и как связана с блокировками — причем так и не понимающего всего этого и сейчас, что только что и продемонстировавшего — в-общем, для абсолютного новичка в теме, не понимающих даже самых базовых вещей, вы слишком неприлично брызгаете слюной. Продолжать, пожалуй, побрезгую, да и бессмысленно.
Это уже теплее, но у автора коммента, на который я отвечал (вы же прочли?), подозрение конкретно на время разбора xml, и отвечал я именно на это. Ну и сравните:
Вы мне предлагаете начать обсуждение уровня ценности сертификатов над уровнем плинтуса? Откажусь, пожалуй, даже несмотря на такую подачу.
конвертация row level блокировки в page lock приводит блокировке посторонних строк, не имеющих отношения к транзакции
Ну вот, хоть что-то полезное по ссылке вычитали. Вот только никакого отношения эта конвертация (которая и есть та самая эскалация) к описываемому случаю страничной блокировки не имеет.
получить блокировку целой страницы можно исключительно в результате эскалации, которая к уровням изолированности транзакций параллельна
Все-таки читать про блокировки. Подсказка для поиска: страничная блокировка при вставке в кучу без блокировки ключей. Даже при вставке одной строки — это хотя бы должно дать понимание, что эскалация тут вообще не при чем и упоминать ее — очень явно выказывать полное непонимание как происходящего, так и самой терминологии.
Именно от уровня изоляции зависят блокировки. С каким-нибудь read committed, например, вы тут получите блокировку на странице данных, где оказались ваши разные наборы данных, и на этом удивленно повиснете.
Странный ответ. Я пишу про блокировки/уровни изоляции. Вы мне отвечаете про блокировки/уровни изоляции (версионные), подтверждая написанное, но выглядит это так, как будто вы с чем-то спорите.
Я вас немного расстрою, с вашего позволения: в любой СУБД легко, не понимая базовой матчасти (блокировки/уровни изоляции), создать подобную ситуацию. У вас ровно этот пример.
Разумеется. Чуть ли ни штатная ситуация даже со небольшими данными, порядка лишь миллионов записей, когда оптимизатор не справляется с оценкой мощности подветвей запросов даже средней (с виду) сложности.
Ну вот, хоть что-то полезное по ссылке вычитали. Вот только никакого отношения эта конвертация (которая и есть та самая эскалация) к описываемому случаю страничной блокировки не имеет.
Все-таки читать про блокировки. Подсказка для поиска: страничная блокировка при вставке в кучу без блокировки ключей. Даже при вставке одной строки — это хотя бы должно дать понимание, что эскалация тут вообще не при чем и упоминать ее — очень явно выказывать полное непонимание как происходящего, так и самой терминологии.
До понимания базовых терминов, извините, говорить не о чем.
Мы разве знакомы?