на 300).
Выборка всегда делается в первую очередь по столбцу с датой (timestamp with timezone), но в выборке всегда есть ограничения по integer и boolean столбцам.
Причем обычно поиск нужен по последнему миллиону записей.
Сейчас выборка работает очень медленно.
Какой лучше построить индекс?
Я не совсем разобрался на сколько хорошо работает индекс по дате в Posgresql. Поэтому не знаю, лучше в составной индекс дату в начало засунуть c сортировкой DESC или сначала булево, потом число, потом дату в конце?
Зависит от селективности условий в первую очередь. То есть по дате отфильтруется миллион записей, ладно. А сколько — по инт и булеан? А от скольки? А есть ли разница в относительном количестве — сначала по цэлому или сначала по дате?
И суть фильтра по дате уточните. Спрашивают с фильтром "за последний год" или именно миллион последних, т.е. если мало подходит под фильтры, до докопает до начала таблицы?
По инту и по булеву выборка десятки миллионов, у них селективность сильно ниже даты. Но когда остается миллион по дате, фильтры по инту и булеву отрезают больше половины данных. Просто как написал, не совсем понял как строится индекс по полной дате со временем и миллисекундами с таймстампом. Лучше булевым и интами отрезать 2/3 из десятков миллионов записей и остатки фильтрануть по дате или дата как то хитро индексируется и он быстро отрежет лям нужных записей, а уже их обработать доп фильтрами. Как будет быстрее?
Там всегда период, просто период относится обычно к последним месяцам. Ну то есть за последний месяц 20 млн записей, а в выборке нужно за 2 недели с начала месяца, типа того.
А много там разных значений инта в запросе? (Булевого понятно что немного).
Просто если одно — то ответ очевиден — инт, бул, дата. Если много — то думать надо. И да, в индэксе по дате нет ничего особенного. Число как число, смысл только спецыфический.
Во, спасибо, это и хотел услышать, тогда получается bool, int, date DESC ?
Если дата как timestamptz — то пожалуй всё равно инт, бул, дата. А если как день — то можэт и нет. Как минимум если на хдд, то можно подумать и про наоборот — дата, бул, инт. На ссд скорее всё равно будет. Впрочем, судя по всему, результаты для всех вариантов будут сопоставимыми.
Благодарю, Вы сильно помогли! Там timestamptz с миллисекундами ещё, поэтому немного ступор был, везде советуют по дате, а Я не мог понять как она хитро индексируется, чтобы выборку срезать. Там же миллисекунды и каждая дата почти уникальна, это как по id составной индекс строить, он всё равно всё обойдет
Ещё периодически встречаюсь с тем, что постгрес как-то не всегда нормально воспринимает несвязанные диапазоны — иношда приходится в подзапросы переделывать.
Обсуждают сегодня