если нам нужно в алфавитном указателе найти какие-то имена. «Руками» мы будем искать следующим образом: посмотрим первую фамилию, найдем нужные имена, пролистнем до следующей фамилии. Это не ограничение b-tree дерева, это ограничение реализации b-tree дерева непосредственно в MySQL. Другие базы так умеют делать — использовать не первую колонку, например, в случае WHERE B=3 индекс в MySQL использоваться, вообще, не будет.
Честно говоря, всегда думал, что это именно ограничение B-деревьев (а точнее особенности их построения по группе полей).
Не могли бы вы привести пример в каким именно СУБД поддерживается возможность эффективного (не full index scan, а index seek) использования индексов в подобных ситуациях? И как это работает?
Postgres 9.5 так не умеет
SQl Server 2016 тоже (прошу прощение за русскую SSMS)
Добавьте в список флаг 9851, отлючающий автоматический merge data и delta checkpoint-файлов
For testing purposes, you might want to turn off automatic merging of files, so that you can more readily
explore this metadata. You can do that by turning on the undocumented trace flag 9851. And of course,
be sure to turn off the trace flag when done testing.
Попробовал поэксперементировать с поведением contain: size.
Поведение почти 1 в 1 как у строго заданных width/height. Однако наткнулся на кое-что странное: https://jsfiddle.net/z3x4sev3/
В Chrome 52.0.2743.116 элемент с display: inline-block и contain: size по умолчанию вертикально выравнен по baseline (слева элемент с contain: size, справа элемент с height: 0, зеленым обозначен их общий родитель):
А вот как замерить производительность с данным свойством и без него я честно говоря не понимаю.
При анимации как вызывающих relayout свойств (font-size, padding), так и не вызывающих (background-color) у одного элемента из 6 тысяч время layout и paint примерно одно и то же не зависимо от установки свойства contain: size на анимируемый элемент (у всех элементов фиксированный width и height). Та же ситуация и с анимацией одновременно 2 тысяч элементов (что с contain: size на каждом, что без него, разницы нет)
O(f(n)) определяет верхнуюю границу сложности алгоритма (т.е. наихудший случай для алгорима), так что не имеет значение в начало или конец массива производится вставка, верхняя граница сложности будет O(n).
Для лучшего случая (т.е. нижней границы сложности алгоритма) есть свое обозначение через Ω, про которое все всегда забывают.
Удаление из B-Tree: обратная операция также интересна. Когда ключ удаляется из узла, Постгрес объединяет одноуровневые узлы, если это возможно, удаляя ключ из их родительского узла. Эта операция также может быть рекурсивной.
И кому верить? Егор Рогов из Postgres Professional говорит, что Postgres не умеет объединять страницы при удалении из B-Tree пруф
Проблема в том, что женщина сама призналась с какой целью приобреталась данная флешка-диктофон. Она сама себя под 138.1 подвела. Вот если бы строила дурочку, может быть все и обошлось бы.
А как они собираются трафик через SSL/TLS хранить? В виде шифрованных пакетов? А смысл? В свете увеличивающейся популярности http/2 идея хранить интернет-трафик пользователя мягко говоря странная.
Во многих маленьких госпиталях вообще нет IT-сотрудников (не говоря уже о специалистах по безопасности), а настройку систем производит «приходящий мастер».
Слияние. Но им вполне можно пользоваться как UPSERT'ом
Скрытый текст
MERGE INTO Sales.SalesReason AS Target
USING (VALUES ('Recommendation','Other'))
AS Source (NewName, NewReasonType)
ON Target.Name = Source.NewName
WHEN MATCHED THEN
UPDATE SET ReasonType = Source.NewReasonType
WHEN NOT MATCHED THEN
INSERT (Name, ReasonType) VALUES (NewName, NewReasonType)
И где их статистику можно посмотреть? Без пруфов как-то голословно.
Честно говоря, всегда думал, что это именно ограничение B-деревьев (а точнее особенности их построения по группе полей).
Не могли бы вы привести пример в каким именно СУБД поддерживается возможность эффективного (не full index scan, а index seek) использования индексов в подобных ситуациях? И как это работает?
http://gsl.azurewebsites.net/Portals/0/Users/dewitt/talks/HekatonWhitePaper.pdf
Поведение почти 1 в 1 как у строго заданных width/height. Однако наткнулся на кое-что странное:
https://jsfiddle.net/z3x4sev3/
В Chrome 52.0.2743.116 элемент с display: inline-block и contain: size по умолчанию вертикально выравнен по baseline (слева элемент с contain: size, справа элемент с height: 0, зеленым обозначен их общий родитель):
А вот как замерить производительность с данным свойством и без него я честно говоря не понимаю.
При анимации как вызывающих relayout свойств (font-size, padding), так и не вызывающих (background-color) у одного элемента из 6 тысяч время layout и paint примерно одно и то же не зависимо от установки свойства contain: size на анимируемый элемент (у всех элементов фиксированный width и height). Та же ситуация и с анимацией одновременно 2 тысяч элементов (что с contain: size на каждом, что без него, разницы нет)
O(f(n)) определяет верхнуюю границу сложности алгоритма (т.е. наихудший случай для алгорима), так что не имеет значение в начало или конец массива производится вставка, верхняя граница сложности будет O(n).
Для лучшего случая (т.е. нижней границы сложности алгоритма) есть свое обозначение через Ω, про которое все всегда забывают.
И кому верить? Егор Рогов из Postgres Professional говорит, что Postgres не умеет объединять страницы при удалении из B-Tree
пруф
.branding {
animation-name: mirror;
animation-play-state: paused;
animation-fill-mode: forwards;
}
@keyframes mirror {
to {
transform:scaleX(1);
}
}
ага, глобальное потепление является причиной уменьшения числа пиратов…
Это прям про хабр. Уже какую неделю, заходя в дайджест, приходится открывать DevTools и прописывать a:visited