typos

Author: le0pard

postgresql_indexes.tex

@@ -91,7 +91,7 @@ \subsection{R-Tree}
 
 \subsection{Hash индекс}
 
-Hash индекс по сути является ассоциативным хеш-контейнером. Хеш-контейнер~--- это массив из разряженных значений. Адресуются отдельные элементы этого массива некоторой хеш-функцией которая отображает каждое значение в некоторое целое число. Т.~е. результат хеш-функции является порядковым номером элемента в массиве. Элементы массива в хеш-конейтнере называются букетами (bucket). Обычно один букет~--- одна странца. Хеш-функция отображает более мощное множество в менее мощное, возникают так называемые коллизии~--- ситуация, когда одному значению хеш-функции соответствует несколько разных значений. В букете хранятся значения, образующие коллизию. Разрешение коллизий происходит посредством поиска среди значений, сохранённых в букете.
+Hash индекс по сути является ассоциативным хеш-контейнером. Хеш-контейнер~--- это массив из разряженных значений. Адресуются отдельные элементы этого массива некоторой хеш-функцией которая отображает каждое значение в некоторое целое число. Т.~е. результат хеш-функции является порядковым номером элемента в массиве. Элементы массива в хеш-конейтнере называются бакетами (bucket). Обычно один бакет~--- одна страница. Хеш-функция отображает более мощное множество в менее мощное, возникают так называемые коллизии~--- ситуация, когда одному значению хеш-функции соответствует несколько разных значений. В бакете хранятся значения, образующие коллизию. Разрешение коллизий происходит посредством поиска среди значений, сохранённых в бакете.
 
 \begin{figure}[ht!]
   \center{\includegraphics[width=1\textwidth]{hash_index.pdf}}
@@ -109,7 +109,7 @@ \subsection{Hash индекс}
 Слабые стороны:
 
 \begin{itemize}
-  \item хеш очень чувствителен к коллизиям хеш-функции. В случае <<плохого>> распределения данных, большинство записей будет сосредоточено в нескольких букетах, и фактически поиск будет происходить путем разрешения коллизий;
+  \item хеш очень чувствителен к коллизиям хеш-функции. В случае <<плохого>> распределения данных, большинство записей будет сосредоточено в нескольких бакетах, и фактически поиск будет происходить путем разрешения коллизий;
   \item из-за нелинейности хэш-функций данный индекс нельзя сортировать по значению, что приводит к невозможности использования в сравнениях больше/меньше и <<IS NULL>>;
   \item данный индекс в PostgreSQL транзакционно небезопасен, нужно перестраивать после краха и не реплицируется через потоковую (streaming) репликацию (разработчики обещают это исправить к 10 версии);
 \end{itemize}