>dimitr
>Это все сочинительство...
Спасибо что поправили. Это было всего лишь предположение.

А позвольте тогда вопрос. Ведь одна запись может иметь несколько версий. И в каждой версии ключевые значения могут быть разные. И на каждую такую версию должна быть ссылка на странице индекса (пусть индекс ссылается на элемент из Pointer Page не так важно). Тоесть фактически в индексе хрянятся ссылки на все версии, в том числе и давно устаревшие.

Пример: когда-то была одна версия записи Id=1. Потом в результате update появилась новая версия Id=2, и стала актуальной (commit). Сейчас когда я делаю select Id from ... where Id=1 сервер вынужден читать страницу на которой когда-то была версия Id=1.

Я понимяю что это нужно для очистки мусора. Но может быть лучше было бы отказатся от такой политики очистки мусора и с целью ускорения поиска по индексу в элементы индекса добавить tra_number? Понятно что это некоторая избыточность, но это значительно ускорит поиск по индексу, а значит и общую производительность.

Если так уж нужна чистка при select то можно будет по tra_number в индексе определить устарела ли версия на которую указывает этот элемент. В таком случае всеравно получаем выиграш за счет того что ненадо читать страници с немусорными записями (ведь мы уже при чтении индекса знаем что они не мусор).

P.S. Вы извините если я глупости давно понятные говорю. Просто проявляю любопытство.

>dimitr
Хм... из статьи в котокой сказано "IB читает все записи таблицы в их естественном порядке собирая пары из ключевого значени и идентификатора записи (так называемого db-key). Затем этот набор сортируется по ключевому значению и создается нижняя часть индекса, со сжатием дубликатов ключевых значений ." мне показало что должно существовать промежуточное звено через которое устанавливается ссответствие "в каких записях были версии с таким ключевым значением".
Аналогия: как промежуточная таблица в отношение могие-ко-многим между "набором сжатых дубликатов ключевых значений" и "записями в таблице"

Вот в элементах этого звена я и предлогал разместить tra_number.

Иначе как установлена связь между "набором сжатых дубликатов ключевых значений" и "записями в таблице"?


>dao+
Стоп секунду. Есть таблица в которой 10001000 записей. 10000000 из них Status=10 у остальных Status<10. При выборке select count(*) where Status<10 сервер действительно замирает на какое-то время. А выборка select count(*) where Status<=9 отрабатывает почти мгновенно. Отсюда можно сделать вывод что я непонимаю термина fullscan который вы привели.

Мда... Лоханулся я немного :)

Но тогда всеравно непонимаю почему это приведет к распуханию индекса. Ведь элементы индекса нижнего уровня итак содержат динамический суффикс+указатели на PointerPage (минимум 4 байта) и наверняка на элемент врутри PP (минимум 1, а скорее 2 байта). А идентификатор транзакции состоит из 4 байт. Тоесть в лучшем случае мы имеем элемент размером 6 байтов, а в худшем 6+полная длина ключа (если нельзя выделить общий префикс). Думаю лишних 4 байта (идентификатор транзакции) небудут лишними и погоды не сделают.

Хотя... Скорее всего я где-то ошибаюсь... Ведь наверняка не я первый такое придумал :)

dimitrСейчас:
<key1><rec_number1>
<key2><rec_number1>

Будет:
<key1><rec_number1><tra_number1>
<key1><rec_number1><tra_number2>
<key2><rec_number1><tra_number3>

Где key >=1 байта, rec_number = tra_number = 4 байта.

Вы меня убили :) Все понятно, слов нет... туплю по черному...

P.S. Спасибо за объяснения.



Все ниженаписаное было придумано и написано до э...озарения :)

dimitr50% прирост среднего размера индекса ты считаешь незначительным?
Хм...
rec_number=4 байта
Key=минимум 3 байта (почему 3: минимум 1 байт на значение и 2 байта на длинну значения. Почему на длинну 2 а не 1: потому что как я слышал в FB2 будет снято ограничени на длинну ключа в 256 байт)

Тоесть уже один элемент имеет минимальную длинну 7 байт. + 4 байта на tra_number будет 11. Тоесть в худшем случае размер индекса увеличится на ~70% от первоначального. Если на ключ приходится 2 байта то на 50%.

Мда... многовато... Хотя увеличение размера страници... Нет! Много... Да еще и если учесть, что худший случай (на ключ 1 байт) случается при индексировании уникальных полей (Id например)... Совсем плохо...

Хотя конечно это тема отдельного исследования, и повышение производительности может покрыть расходы HDD и RAM...

Кстати, сейчас ведь чтение осуществляется так как сказано в стаье . Если да то пример:

Есть база с размером страници 4096.
Есть индекс с глубиной 3.
Сейчас чтение: Индекс(L2)->Индекс(L1)->Индекс(L0)->PP->DP =4096*5=20480 байт

Таже база с размером страници 8192 и с tra_number в индексе.
Чтение: Индекс(L2)->Индекс(L1)->Индекс(L0) =8192*3=24576 байт

Тоесть при глубеине индекса 3 объем чтения увеличится на 20% от начального, при глубине 4 (я такого ниразу не встречал) на ~33%.