"их использовать точно надо"

Использование индекса в этом запросе не может дать кардинального ускорения, потому что нет условия "where" и посчитать надо все! записи в таблице, так какая разница - пробегать весь миллион записей по таблице или по индексу?

Можно заставить постгрес использовать индекс в таком запросе:

# explain select count(*) from test_table;
Aggregate (cost=99704.51..99704.51 rows=1 width=0)
-> Seq Scan on test_table (cost=0.00..88396.01 rows=4523401 width=0)

# set enable_seqscan to off;

# explain select count(id) from ( select id from test_table order by id ) as a;
Aggregate (cost=17753473.89..17753473.89 rows=1 width=4)
-> Subquery Scan a (cost=0.00..17742165.38 rows=4523401 width=4)
-> Index Scan using test_index on test_table (cost=0.00..17742165.38 rows=4523401 width=4)

Однако это будет работать намного! дольше (например на таблице в миллион записей) чем seq_scan, потому что для каждой записи найденной по индексу постгрес будет вытягивать соответствующую строку из таблицы.

P.S.: Оракл использует для такого запроса индекс, и выполняет его быстрее, чем seq_scan из-за того, что для каждой записи найденной по индексу он не! вытягивает строку из таблицы, а считает (count) прямо по записи из индекса. А пробежать по индексу немного! быстрее, чем по таблице, если, например, в нем проиндексированы не все поля таблицы.

ID Operation Object UP Cost
---- ---------------------------------------- ----------------- --- ------
0 SELECT STATEMENT, 1526
1 SORT, AGGREGATE 0 1
2 INDEX, FAST FULL SCAN TEST_TABLE 1 1

"разница существенная - идексы обычно значительно меньше, т.е. операций READ меньше на порядки"

"Существенная" (~10), но не "кардинальная" (~1000) (как например для запросов с ограничением). (Это не обозначает, что я голосую за то, чтобы постгрес не улучшил свое поведение в этом вопросе.)

"это совсем не то запрос, который предлагался"

Возможно. Этот кажется более похожим (в таблице все id>=0):

# set enable_seqscan to off;
# explain select count(id) from test_table where id >= 0;
Aggregate (cost=17763139.20..17763139.20 rows=1 width=4)
-> Index Scan using test_index on test_table (cost=0.00..17751831.75 rows=4522982 width=4)

(Однако его цена по оценке постгреса очень похожа на предыдущий: 17763139.20 и 17753473.89).

Но и окончания его выполнения у меня не хватило терпения дождаться. В то время как seq_scan отработал за приемлемое время.

"ИМЕННО, и это есть нормальное поведение."

Согласен.

"Откуда сведения, что постгрес так не делает? Ссылку в студию!"

Только из опыта. Могу предложить вам задать вопрос на postgresql.org.

"не увидел ответа на поставленный вопрос"\r
\r
Ответ на вопрос в топике есть: "потому что для каждой записи найденной по индексу постгрес будет вытягивать соответствующую строку из таблицы", "oracle ... не! вытягивает строку из таблицы, а считает (count) прямо по записи из индекса".\r
\r
Нет ответа на вопрос: "почему бы Постгресу не действовать в этом запросе аналогично Ораклу?"\r
\r
"Кто нибудь вообще может поделиться личным опытом сравнения скорости работы Postgres с другими RDBMS?"\r
\r
Мне кажется, что нужно сравнивать не только скорость. /topic/26963