У цій серії статей йтиметься про індекси в PostgreSQL.
Будь-яке питання можна розглядати з різних точок зору. Ми будемо говорити про те, що повинно цікавити прикладного розробника, що використовує СУБД: які індекси існують, чому в PostgreSQL їх так багато різних, і як їх використовувати для прискорення запитів. Мабуть, тему можна було б розкрити і меншим числом слів, але ми потай сподіваємося на допитливого розробника, якому також цікаві і подробиці внутрішнього устрою, тим більше, що розуміння таких подробиць дозволяє не тільки прислухатися до чужої думки, але і робити власні висновки.
У першій частині ми говорили про те, що метод доступу повинен надавати інформацію про себе. Подивимося, як влаштований цей інтерфейс.
Всі властивості методів доступу представлені в таблиці pg_am (am - access method). З цієї таблиці можна отримати і сам список доступних методів: btree, hash, gist, gin, spgist, brin
Хоча до методів доступу можна з повним правом віднести і послідовне сканування, історично склалося так, що воно відсутнє в цьому списку.
У першій статті ми розглянули механізм індексування PostgreSQL, у другій - інтерфейс методів доступу, і тепер готові до розмови про конкретні типи індексів. Почнемо з хеш-індексу.
Багато сучасні мови програмування включають хеш-таблиці в якості базового типу даних. Зовні це виглядає, як звичайний масив, але в якості індексу використовується не ціле число, а будь-який тип даних (наприклад, рядок). Хеш-індекс в PostgreSQL влаштований схожим чином. Як це працює?
Ми вже розглянули механізм індексування PostgreSQL і інтерфейс методів доступу, а також один з методів доступу - хеш-індекс. Зараз поговоримо про самому традиційному і використовуваному індексі - B-дереві. Глава вийшла великий, запасайтесь терпінням.
Індекс btree, він же B-дерево, придатний для даних, які можна відсортувати. Іншими словами, для типу даних повинні бути визначені оператори «більше», «більше або дорівнює», «менше», «менше або дорівнює» і «дорівнює». Зауважте, що одні й ті ж дані іноді можна сортувати різними способами, що повертає нас до концепції сімейства операторів.
GiST - скорочення від «generalized search tree». Це збалансоване дерево пошуку, точно так же, як і розглянутий раніше b-tree.
У чому ж різниця? Індекс b-tree жорстко прив'язаний до семантиці порівняння: підтримка операторів «більше», «менше», «дорівнює» - це все, на що він здатний (зате здатний дуже добре!). Але в сучасних базах зберігаються і такі типи даних, для яких ці оператори просто не мають сенсу: годинне, текстові документи, картинки ...
На п'ятій частині цикл статей про індекси в СУБД PostgreSQL не закінчується і вже зараз Єгор Рогов пише продовження.
