Намного лучшая производительность (чтение) для типа INT, чем SMALLINT

У меня есть таблица с 1,3 миллиона строк

У меня был smallint (индексированный) столбец в этой таблице, и когда я выполнял очень простой запрос:

select * from table where field = x order by id limit 100

иногда (когда я менял x на разные значения) запрос был очень медленным (иногда 10-20 секунд).

Затем я изменил этот столбец на тип int, а также создал индекс для этого столбца.

Теперь те же запросы выполняются намного быстрее, чем предыдущие, почти всегда они занимают не более 1 секунды.

Таким образом, smallint занимает меньше места на диске, но чтение типа int выполняется намного лучше.

Это правильно? если да, то почему?


person Oto Shavadze    schedule 08.10.2016    source источник
comment
Можете ли вы опубликовать воспроизводимый тестовый пример, чтобы я мог его опробовать?   -  person Laurenz Albe    schedule 08.10.2016


Ответы (1)


Причина, вероятно, в перекосе данных или устаревшей статистике индекса.

Первый - это распределение ценностей. Если в столбце всего несколько значений, Postgres достаточно умен, чтобы не использовать индекс. Итак, это зависит от избирательности индекса.

То же самое может произойти, если необходимо обновить статистику индекса.

Маловероятно, что причиной этого будет разница в типах данных. Скорее всего, создаваемый свежий индекс имеет актуальную статистику.

person Gordon Linoff    schedule 08.10.2016
comment
В поле около 5000 уникальных значений. В обоих случаях иногда использовался индекс, иногда нет, но тип int намного быстрее, чем был smallint. Также я обновлял старый (smallint) индекс (отброшен и воссоздан), но в любом случае некоторые запросы по-прежнему были медленными для типа smallint - person Oto Shavadze; 08.10.2016
comment
Разница в размере индекса и, возможно, выравнивание значений может привести к разнице в производительности. Но это не приведет к сдвигам на порядки, когда более медленная версия занимает несколько секунд. Настоящая проблема заключается в том, используется ли индекс. - person Gordon Linoff; 08.10.2016