not null
some_id integer not null,
start_time timestamp without time zone not null
Есть ещё ряд полей в этой таблице, но они в контексте описываемой мною проблемы роли, как мне кажется, не играют.
по каждому из этих полей построены Btree индексы. Сама таблица занимает 8Gb.
При выполнении запроса:
SELECT t.id AS t_id_0 FROM some_test AS t WHERE t.some_id = 3 AND ( t.start_time >= <some timestamp> AND t.start_time <= <some timestamp> )
для одних 30 суточных промежутков времени запрос выполняется за 1-3 секунды, но встречаются 30 суточные промежутки времени, для которых запрос выполняется уже 14-20 секунд.
Сам параметр some_id может принимать 15 значений. Для каждого из этих значений кол-во записей.в этой таблице очень сильно варьируется: от нескольких тысяч до нескольких лесятков миллионов.
Как в данной ситуации выровнять время выполнения селекта для всех значений some_id?
Индексы эффективны для столбцов с большим количеством значений. Если одному some_id соответствуют миллионы записей, то селективность такого запроса будет никакой, из-за чего база выполняет фуллскан
Обсуждают сегодня