Почему Postgresql ищет текстовый индекс быстрее индекса Int?

Question

CREATE TABLE index_test 
(
    id int PRIMARY KEY NOT NULL, 
    text varchar(2048) NOT NULL, 
    value int NOT NULL 
); 
CREATE INDEX idx_index_value ON index_test (value); 
CREATE INDEX idx_index_value_and_text ON index_test (value, text); 
CREATE INDEX idx_index_text_and_value ON index_test (text, value); 
CREATE INDEX idx_index_text ON index_test (text); 

Таблица заполнена 10000 случайными строками, столбец «значение» имеет целые числа от 0 до 100, столбец «текст» имеет случайный хэш-бит 128 бит md5. Извините за использование неправильных имен столбцов.

Мои поиски:

select * from index_test r where r.value=56; 
select * from index_test r where r.value=56 and r.text='dfs'; 
select * from index_test r where r.text='sdf'; 

В любое время я сделать некоторые поиск ...

1. если только индексы на 'текст' и/или 'стоимость' столбцов представлены
2. в сочетании («текст» и «значение» вместе) показаны

... поэтому, в любое время я вижу следующее изображение:

Поиски целого столбца 'значение' является

• медленнее
• сложена из 2 поиска: * Растровые кучного сканирования на index_test * и * Растровые сканирования индекса на idx_index_value *

Поиск по столбцу "текст" varchar:

• более быстрый
• всегда с помощью индексного сканирования

Почему поиск строки проще, чем поиск целых чисел? Почему поисковые планы отличаются таким образом? Есть ли подобные ситуации, когда этот эффект может быть воспроизведен и может быть полезен для разработчиков?

Answer 1

Поскольку текст является хешем, уникальным по определению, будет только одна строка из строк 10k таблицы, соответствующей этому тексту.

Значение 56 будет существовать около 100 раз внутри строк 10 тыс., И оно будет разбросано по всей таблице. Поэтому планировщик идет первым в индекс и находит страницы, где находятся эти строки. Затем он посещает каждую из этих разбросанных страниц для извлечения строк.