Merge pull request #30 from avallac/information_adbout_self_balancing

B-Tree is self-balancing

Author: le0pard

postgresql_indexes.tex

@@ -48,14 +48,14 @@ \subsection{B-Tree}
   \item сохраняют сортированность данных;
   \item поддерживают поиск по унарным и бинарным предикатам (\lstinline!<a; = b; >c and <d; <e and >f!) за O($\log_m{N}$), где m~--- количество записей в блоке, N~--- количество элементов;
   \item позволяют не сканируя последовательность данных целиком оценить cardinality (количество записей) для всего индекса (а следовательно таблицы), диапазона, причём с произвольной точностью. Посмотрели корневую страницу~--- получили одну точность. Посмотрели следующий уровень дерева~--- получили точность получше. Просмотрели дерево до корня~--- получили точное число записей;
+  \item самобалансируемый, для внесения изменения не требуется полного перестроения, происходит не более O($\log_m{N}$) дейстий, , где m~--- количество записей в блоке, N~--- количество элементов;
 \end{itemize}
 
 Слабые стороны B-Tree индексов:
 
 \begin{itemize}
-  \item для их построения требуется выполнить полную сортировку пар (Значение, RowId);
   \item занимают много места на диске. Индекс по уникальным Integer-ам к примеру весит в два раза больше аналогичной колонки (т.к. храняться ещё и RowId);
-  \item при постоянной записи дерево разбалансируется, а также начинает хранить данные разреженно (сразу после построения они могут лежать очень плотно), и время доступа увеличивается за счёт увеличения объёма дисковой информации. Поэтому B-Tree индексы требуют присмотра и периодического перепостроения (REBUILD);
+  \item при постоянной записи дерево начинает хранить данные разреженно (сразу после построения они могут лежать очень плотно), и время доступа увеличивается за счёт увеличения объёма дисковой информации. Поэтому B-Tree индексы требуют присмотра и периодического перепостроения (REBUILD);
 \end{itemize}