И еще вопрос Читаю книгу, и там пишут, что индекс

для такого запрос
SELECT * FROM coordinates WHERE longitude > 51.21321 AND
longitude < 100.21323 AND latitude > 21.123123 AND latitude < 23.123123;
Будет не эффективено выполняться. Вопрос почему? Разве для btree index сложно выбрать значения между ?

> Подскажите, есть ли отличие custom и concatenated index? А откуда эта терминология, вообще (про отличия надо спрашивать того, кто её придумал)? > Я так понимаю, что БД поняла, что данных в таблице нет и использовать индекс нет смысла? Если гадать — то, скорее всего, случился autovacuum / autoanalyze, и таки да, "поняла". > Разве для btree index сложно выбрать значения между ? Разумеется, сложно. Вам стоит разобраться, как он устроен (или, для начала, понять на уровне аналогий — обычно приводят примеры отсортированного массива, телефонного справочника и индекса (алфавитного указателя) в книгах — в каждом из них тоже [может быть] составной ключ).

Сложность в том , что нужно искать в двух диапазонах ? Или запрос с одним диапазоном тоже сложный был бы?

Да. Нет. Разберитесь, как устроен b-tree индекс — это основной (а в некоторых — и единственный, наверное) тип индекса во всех "классических" RDBMS, поэтому изучить его полезно.

Ну что значит разберись. Я плюс минус знаю как оно работает. Есть дерево, есть уровни с ссылками на другие уровни со значениями меньше или больше. В конце ссылки введут на место в памяти, где уже и лежат сами значения.

Если знаете, то почему с вопросами выше какие-то сложности?

Смотрите, допустим у вас не составной индекс. Тогда он использует только индекс по лонгитюду например, а латитюд ему придется тупо фильтровать.

А составной индекс не поможет, потому что будет слишком много уникальных значений латитюда и он по сути просто сведется к несоставному

И дажэ если бы не слишком много — с оптимизацыями пропусков в постгресе пока тяжко.

Так сложность заключается не в том, что по двум параметрам искать, а в том, что нужно искать между двумя значениями ?

Это да... почти везде уже есть, а у нас так и нет. ;( Я даже помню, как я общался с кем-то, кто хотел "для себя" написать какой-то инструмент (не помню, зачем там была СУБД), и просто выкинул PostgreSQL из списка поддерживаемых им СУБД именно поэтому (только в нём какой-то важный запрос выполнялся неприемлемо долго).

В одномерном случае все хорошо и быстро, но представьте, что у вас после выборки по первому индексу осталась миллион точек. Что делать? Индекс уже не используешь. Только секскан

Что имеется ввиду под одномерным в случае индексов ? Ну если у тебя составной индекс по (field1,field2), то запрос where field1=… and field2=… должен работать быстро Найдет записи сразу по первому полю, а из них Найдет по второму

Ваши сложности заключаются в том, что Вы не даёте себе труда подумать пару минут, уж извините. Если Вы собираетесь работать с СУБД — у Вас ещё немало будет подобных вопросов, а простое представление дало бы Вам ответы на большинство из них. "Знание одного принципа заменяет тысячу фактов" и т.п.

Как найдет?:) попробуйте на бумажке нарисовать

Если Вам не нравится аналогия с алфавитным указателем — та, что с отсортированным массивом и бинарным поиском, ничуть не хуже. Т.е. индекс по (field1,field2) по сути эквивалентен массиву, отсортированному по (мульти)ключу (field1,field2).

Мне нравится аналогия, но я видно ее не понял. Отыскать значения с фамилией начинающиеся на букву от В до Г это сложно ? Я не знаю как там будет бегать этот указатель по дереву, но мне кажется он найдет сразу уровень на котором будет левая граница. Дальше надо найти где правая граница. Тут конечно может придется начинать бежать с начала

Yaroslav Schekin
Да какие деревья?! ;) Вы в жизни видели телефонный...

Ну тут да, придется просто бежать по всем значениям в диапазоне, чтобы собрать индексы.

Ну так b-tree индексы по сути работают аналогично — в этом примере легко найти все страницы по первому ключу (от "Теорема" до "Тип", например), а вот найти что-нибудь по второму (например, "логический/ая" — куда сложнее).