# explain select * from emails where category_id > 2;
QUERY PLAN
------------------------------------------------------------
Seq Scan on emails (cost=0.00..22.50 rows=333 width=154)
Filter: (category_id > 2)
(записей: 2)

# explain select * from emails where category_id = 2;
QUERY PLAN
------------------------------------------------------------------------------
Index Scan using emailsndx1 on emails (cost=0.00..17.07 rows=5 width=154)
Index Cond: (category_id = 2)
(записей: 2)


Если я правильно понимаю эту информацию, то при условии 'category_id = 2' используется индекс, а при условии 'cetegory_id > 2' - нет (т.е. осуществляется полный перебор)

Почему так происходит? Индекс же есть!

автор"(записей: 2)" - Это обозначает что в таблице две строки с category_id > 2, и две - с category_id = 2?

Нет - записей в таблице 1.000.000. Я её только что создал и не удалял и не редактировал, так что vacuum тут не причём

А вообще какой тип индексов лучше использовать для внешних ключей?
Я читал что индексы btree лучше использовать для числовых полей и полей типа дата/время. А hash - для текстовых полей.
Также пишут что btree лучше подходит для операций <, > и сортировки, а hash - для = и <>.
Внешний ключ - число, применяется операция сравнения. Что выбрать?

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

И ещё несколько наболевших вопросов:
1) Правда ли что unique индексы быстрее, чем простые индексы?
2) При таких объёмах стоит ли индексировать поле типа boolen (имеется/отсутствует)? Может оно без индекса быстрее будет?
3) Стоит ли индексировать поле типа varchar(255) - наименование. По нему будет производится поиск с помощью оператора like (скорее всего на плное вхождение: '%template%')? Eсли стоит, то каким индексом? Hash?

Очень нужна помощь в этом вопросе! Буду длагодарен любым советам.

авторТаблица будет иметь несколько миллионов записей.
Уточнение: даже несколько десятков миллионов (от 10.000.000 до 100.000.000)

авторЕсли это не поможет, то приведите пожалуйста результат работы двух ваших explain запросов с ключом analyze:
explain analyze select * from emails where category_id > 2;
explain analyze select * from emails where category_id = 2;

# explain analyze select * from emails where category_id = 2;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------
Index Scan using emailsndx1 on emails (cost=0.00..17.07 rows=5 width=154) (actual time=180.16..41126.74 rows=10130 loops=1)
Index Cond: (category_id = 2)
Total runtime: 41150.82 msec
(записей: 3)

# explain analyze select * from emails where category_id > 2;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------
Seq Scan on emails (cost=0.00..22.50 rows=333 width=154) (actual time=28.41..6218.24 rows=979922 loops=1)
Filter: (category_id > 2)
Total runtime: 6955.11 msec
(записей: 3)

Вот такие результаты.
Вопрос: analyze собирает статистику для последующей оптимизации. Это значит что analyze нужно делать для всех запросов:
analyze select * from emails where category_id = 1;
analyze select * from emails where category_id = 2;
........
analyze select * from emails where category_id > 1;
analyze select * from emails where category_id > 2;
..........
или достаточно analyze select * from emails?

авторРезультаты двух "explain analyze ...", которые вы привели получены после выполнения "vacuum analyze emails"? Вы сделали "vacuum analyze emails"?

После этой процедуры вот что получилось:
# explain analyze select * from emails where category_id = 2;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------
Seq Scan on emails (cost=0.00..20322.01 rows=13333 width=28) (actual time=43.04..8796.18 rows=10130 loops=1)
Filter: (category_id = 2)
Total runtime: 8812.18 msec
(записей: 3)

# explain analyze select * from emails where category_id > 2;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------
Seq Scan on emails (cost=0.00..20322.01 rows=973914 width=28) (actual time=35.24..8336.33 rows=979922 loops=1)
Filter: (category_id > 2)
Total runtime: 9116.29 msec
(записей: 3)

Оптимизатор совсем отказался от индексирования?

авторset enable_seq_scan to off;
explain analyze select * from emails where category_id = 2;
explain analyze select * from emails where category_id > 2;

# explain analyze select * from emails where category_id = 2;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------
Seq Scan on emails (cost=0.00..20322.01 rows=13333 width=28) (actual time=43.04..8796.18 rows=10130 loops=1)
Filter: (category_id = 2)
Total runtime: 8812.18 msec
(записей: 3)

# explain analyze select * from emails where category_id > 2;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------
Seq Scan on emails (cost=0.00..20322.01 rows=973914 width=28) (actual time=35.24..8336.33 rows=979922 loops=1)
Filter: (category_id > 2)
Total runtime: 9116.29 msec
(записей: 3)

Извиняюсь, наврал: вот правильные результаты:

# explain analyze select * from emails where category_id = 2;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------
Index Scan using emailsndx1 on emails (cost=0.00..47007.67 rows=13333 width=28) (actual time=158.83..42997.30 rows=10130 loops=1)
Index Cond: (category_id = 2)
Total runtime: 43037.43 msec
(записей: 3)

# explain analyze select * from emails where category_id > 2;
а здесь psql виснет....

Спасибо за помощь.

А что вы можете сказать об этом: авторКакой тип индексов лучше использовать для внешних ключей?
Я читал что индексы btree лучше использовать для числовых полей и полей типа дата/время. А hash - для текстовых полей.
Также пишут что btree лучше подходит для операций <, > и сортировки, а hash - для = и <>.
Внешний ключ - число, применяется операция =. Что выбрать?

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

И ещё несколько наболевших вопросов:
1) Правда ли что unique индексы быстрее, чем простые индексы?
2) При таких объёмах стоит ли индексировать поле типа boolen (имеется/отсутствует)? Может оно без индекса быстрее будет?
3) Стоит ли индексировать поле типа varchar(255) - наименование. По нему будет производится поиск с помощью оператора like (скорее всего на плное вхождение: '%template%')? Eсли стоит, то каким индексом? Hash?

Очень нужна помощь в этом вопросе! Буду длагодарен любым советам.