Pull to refresh

Comments 15

Подскажите пожалуйста. Активно использую PostgreSQL на работе. Но постоянно ощущаю, что использую его в основном как блекбокс — не особо вникая во внутренности работы.

Хотел глубоко разобраться с тем как работает внутри.
1. Как хранятся данные таблиц и индексов на диске.
2. Что происходит при изменении данных, по которым есть индексы.
3. Виды индексов, внутреннее устройство. В каких случаях какие создавать
итд итп.

Вообщем можно сказать хочу разобраться с внутренностями PostgreSQL.
Посоветуйте материалы.
Спасибо.

Третий пункт по идее должен закрываться этим циклом статей (плюс документация, конечно).
А по первым двум со всей скромностью рекомендую наши курсы: DBA1 (модули "Архитектура" и "Организация данных") и DBA2 (модуль "Изоляция и многоверсионность").
Если хочется копнуть еще глубже — тогда смотреть какие-то отдельные статьи и читать исходный код (:

Вау! Спасибо и за весь цикл, и за конкретно эту статью — очень полезно. Насчёт столбцов, содержащих всего пару значений, например, М и Ж, то если мы будем добавлять сначала всех М, а потом всех Ж, то индекс тоже имеет смысл строить?

На здоровье, рад, что понравилось.


Насчет вопроса. Сложновато представить, что такой порядок появится каким-то естественным путем, но если да — то можно. Но только надо смотреть на распределение, чтобы понимать, что от такого индекса ждать.
Скажем, если М и Ж примерно поровну, то выиграть получится только 50% (минус накладные расходы на построение битовой карты).
Другая крайность — если, допустим, М очень много, а Ж очень мало, то может лучше сделать частичный индекс btree where Ж, потому что для Ж он и так будет маленький, а для М индекс вообще не будет иметь смысла.

А в каких ситуация PostgreSQL предпочитает brin индекс btree?
Есть 2 индекса по одному и паре полей, но почему-то brin используется чаще чем btree. С чем это может быть связанно?

Какие-то конкретные ситуации я затрудняюсь обозначить. Планировщик всегда выбирает тот план, который имеет — по его оценкам — наименьшую стоимость.
Стоимость доступа по индексу рассчитывается, принимая во внимание предполагаемую селективность условия (какую долю строк придется выбрать из таблицы), корреляцию с расположением строк на диске и другие факторы. В том числе, конечно, и внутреннее устройство индекса, так что btree оценивается по одному алгоритму, а brin — по другому. У кого получится меньше число, тот и победил.
Если интересны алгоритмы вычисления стоимостей, можно заглянуть в selfuncs.c (функции btcostestimate и brincostestimate), но вряд ли это добавит ясности.


А на самом-то деле нет резона держать оба индекса на одном поле.

Мы для эксперимента такое делали, когда только brin появились.
Есть предположение, что есть запрос с агрегацией данных, то brin чаще выбирается, чем btree. Но это только догадка.
Нашёл статью, пока пытался разобраться с неиспользующимся BRIN-индексом в PostGIS.
В общем, инфраструктуре BRIN нужно, чтобы кто-то посчитал Correlation статистику, и чтобы она была значительно больше 0, иначе оно скажет «надо читать индекс целиком» на планировании. Кажется, это бага и в постгисе и в типе box.
trac.osgeo.org/postgis/ticket/4625#ticket

Я там в hackers написал, что думаю, ну и тут повторю.
Имхо по уму корреляция должна вычисляться для пары (атрибут, индекс), т. е. для каждого индекса (или может типа индекса?) — по-своему, с учетом того, в каком порядке именно этот индекс возвращает значения.
А сейчас корреляция считается только для сортируемых типов в предположении, что в индексе значения лежат отсоортированными. То есть, по сути, это работает правильно только для B-деревьев.

для того, как она используется в том месте планировщика, нужно считать не корреляцию, а оверлап между соседними страницами брина. здорово, что её придумали для одномерных типов считать через корреляцию, но не очень правильно так поступать для многомерных.

Спасибо за статью. Тоже обнаружил, что BRIN ломает HOT. Вы не проводили проверку, это сложно исправить?

Оказалось, что непросто. В 15-ю версию вкатили патч, который должен быть это исправить, а потом откатили обратно - оказалось, не все учли. Теперь может в 16-й версии поправят, вроде шансы есть.

Sign up to leave a comment.