и timestamp
- s_id около 20к сейчас (может быть 100к в будушем)
- p_id считанный десяток
- ts на каждую минуту
как всегда хочется, чтобы индекс был минимальный и максимально быстрый, и я вот не могу вспомнить, какой там правильный порядок для колонок поставить
вроде сперва с самой маленькайо cardinality, потом больше? напомните пожалуйста
(таблица еще будет по ts партицированна. но это другой вопрос)
Если таблица будет партиционирована то ts у вас первое поле индекса в любом случае т.к. постгрес не умеет в глобальные индексы. Далее обычно по убыванию селективности - s_id, p_id
Зависит практически исключительно от операцый. Если только = на все три поля -- то вообще без разницы, например. cardinality можэт сделать какие-то варианты безсмысленными для упорядоченного поиска не первых полей индэкса, да. Но опять всё зависит от того, что ищем.
>т.к. постгрес не умеет в глобальные индексы. Что, однако, совершэнно не требует ставить ts первым. Более того, учитывая особенности ts (чаще всего ищут по диапазону, чаще всего значения плюс-минус уникальны) -- как раз после ts что-то ставить ужэ не очень полезно.
его не придется ставить, у вас партиция индекса уже будет базироваться на диапазоне ts
При чём тут вообще это?
Как будто от того, что у нас есть диапазон ts -- индэкс автоматически перестаёт быть нужэн!
при том что если вы не укажете в запросе ts то будут просмотрены ВСЕ партиции индекса, что по сути похоже на скипскан составного индекса (ts,s_id,p_id)
И кстати еще проблема уникальности. Можно притворяться что в постгресе "не обязательно ставить ts первым", но когда встает вопрос глобальной уникальности то выясняется что ts там уже давно стоит не смотря на то что его там вроде бы "нет".
>то будут просмотрены ВСЕ партиции индекса, Конечно. Или если указать неправильно. >то по сути похоже на скипскан составного индекса Ну и? Тем более, что партицый обычно не так много -- и это скипскан с небольшой кардинальностью. Впрочем, это отход от темы всё. Ещё раз -- если ts указан точно -- то порядок вообще не будет важэн. Если диапазоном -- то ужэ появляются вопросы к кардинальности всех остальных условий. И если она строго равна один (указаны точно) -- то ts как раз нужно будет ставить последним. И это совершэнно независимо от области значений ts -- поделены они на партицыи или нет.
в запросах там всегда участвует ts, то есть партиции 100% отсекаются и чаще всего 1 будет интересна
ну и посудите сами - 1 у вас всегда указывается ts, 2 это самое селективное поле в данном случае смысл городить партиционированный по ts индекс в котором "отсутствует" поле ts :))
Обсуждают сегодня