Комментарии 15
Всегда пожалуйста!
Хотел глубоко разобраться с тем как работает внутри.
1. Как хранятся данные таблиц и индексов на диске.
2. Что происходит при изменении данных, по которым есть индексы.
3. Виды индексов, внутреннее устройство. В каких случаях какие создавать
итд итп.
Вообщем можно сказать хочу разобраться с внутренностями PostgreSQL.
Посоветуйте материалы.
Спасибо.
Третий пункт по идее должен закрываться этим циклом статей (плюс документация, конечно).
А по первым двум со всей скромностью рекомендую наши курсы: DBA1 (модули "Архитектура" и "Организация данных") и DBA2 (модуль "Изоляция и многоверсионность").
Если хочется копнуть еще глубже — тогда смотреть какие-то отдельные статьи и читать исходный код (:
На здоровье, рад, что понравилось.
Насчет вопроса. Сложновато представить, что такой порядок появится каким-то естественным путем, но если да — то можно. Но только надо смотреть на распределение, чтобы понимать, что от такого индекса ждать.
Скажем, если М и Ж примерно поровну, то выиграть получится только 50% (минус накладные расходы на построение битовой карты).
Другая крайность — если, допустим, М очень много, а Ж очень мало, то может лучше сделать частичный индекс btree where Ж, потому что для Ж он и так будет маленький, а для М индекс вообще не будет иметь смысла.
Есть 2 индекса по одному и паре полей, но почему-то brin используется чаще чем btree. С чем это может быть связанно?
Какие-то конкретные ситуации я затрудняюсь обозначить. Планировщик всегда выбирает тот план, который имеет — по его оценкам — наименьшую стоимость.
Стоимость доступа по индексу рассчитывается, принимая во внимание предполагаемую селективность условия (какую долю строк придется выбрать из таблицы), корреляцию с расположением строк на диске и другие факторы. В том числе, конечно, и внутреннее устройство индекса, так что btree оценивается по одному алгоритму, а brin — по другому. У кого получится меньше число, тот и победил.
Если интересны алгоритмы вычисления стоимостей, можно заглянуть в selfuncs.c (функции btcostestimate и brincostestimate), но вряд ли это добавит ясности.
А на самом-то деле нет резона держать оба индекса на одном поле.
В общем, инфраструктуре BRIN нужно, чтобы кто-то посчитал Correlation статистику, и чтобы она была значительно больше 0, иначе оно скажет «надо читать индекс целиком» на планировании. Кажется, это бага и в постгисе и в типе box.
trac.osgeo.org/postgis/ticket/4625#ticket
Я там в hackers написал, что думаю, ну и тут повторю.
Имхо по уму корреляция должна вычисляться для пары (атрибут, индекс), т. е. для каждого индекса (или может типа индекса?) — по-своему, с учетом того, в каком порядке именно этот индекс возвращает значения.
А сейчас корреляция считается только для сортируемых типов в предположении, что в индексе значения лежат отсоортированными. То есть, по сути, это работает правильно только для B-деревьев.
Спасибо за статью. Тоже обнаружил, что BRIN ломает HOT. Вы не проводили проверку, это сложно исправить?
Индексы в PostgreSQL — 9