interestingHint - index range scan.

Что бы дать понять, что я в теме.
неа
мимо темы:
Reverse Key IndexesMany database tables have primary or unique keys based on a sequence. These keys are usually indexed by b-tree indexes which, by nature, store the indexed values in order. This behavior of sequential storage gives this type of index the name of “monotonic” or “right-growing” index. These types of indexes can become performance bottlenecks on high-volume transactional systems because of serialization that occurs when inserting values into the leaf-blocks of these indexes.

To avoid this serialization, reverse-key indexes can be used. A reverse-key index stores indexed values in reverse-bit order. So, where the values (234, 235, 236) are stored sequentially and contiguously in a normal b-tree index, they are stored out of sequence and non-adjacent (236, 234, 235) for the reverse-key index (see Table 2-3). Over a larger set, this reversing of the key distributes the indexed values across the leaf-node blocks of the index, thereby eliminating the serialization on sequential inserts.

interesting
Суть проблемы с index range scan
содержится в приведенной Вами цитате.

попытка наковырять недостатки зачетная но не совсем понятно, что оно меняет в плане наличия отсутствия такого индекса в мсскл. да, чудо лекарством от всех болезней оно не станет, при like конечно же начнет фулсканить, но по строгому соответствию достанет именно по index range scan реверсного индекса.

interesting
Интересно , а исходя из каких критеривев крутости (преймущественности) в список попал этот пункт ?

я ответил на поставленный вопрос ?

interesting
Не количеством, как таковым,
а самим фактом наличия слотов транзакций
в блоках данных и индексов и логикой работы с ними.

атрибуты транзакции в блоке данных то тут каким боком ? перечитайте мою цитату из доки, ва куда понесло совсем не туда.

interestingИМХО Присутствие Reverse key indexes не совсем соответствует цитате,

а вот эту конструктивней, подправлю. за одно можно показать какой бенефит кластерный индекс дает, помнится я pkarklin показывал.

interesting
Имелось ввиду , не сами атрибуты, а их количество на блок
относительно количества строк ( ключей) в блоке и
конкуренция за доступ к слотам.
атрибуты чего ? транзакции - бред, нет в индексе никаких атрибутов транзакции.
конкуренция за leaf блок происходит в любой субд.

interesting
Вы хотите сказать что при изменении ( добавлении ) ключа в индексном блоке
не занимается ( используется) слот транзакций из этого блока ?
нет кончено, откуда же ему взяться в блоках индекса, атрибуты транзакции в блоке данных, а не индекса хранятся.

interestingЕще раз
вы еще раз повторили глупость, разберитесь в структуре блока индекса и данных и возвращайтесь с новым тезисом ;)

ок, убедил. с ITL в блоках индекса я слунил.
но всетаки возвращаемся к
interesting
Если смотреть в суть проблемы, то фича появилось
как затычка архитектурной проблемы ограниченного количества
слотов транзакций в блоке данных.
в реальности у индекса не произойдет ограничения, если в блоке не хватает места под ITL этот блок индекса просто разбивается на два. в свою очередь мсскл при привышении кол-ва блокировок проэскалирует блокировки до блокировки всей таблицы.