Я бы не подумал, что индексированная таблица обязательно будет быстрее сканировать, чтобы подсчитать все видимые кортежи. По логике вещей, он должен был бы проходить один и тот же объем данных, независимо от того, организован ли он так, что данные находятся в конечных узлах b-дерева или в существующем формате кучи.
В настоящее время индексы postgresql хранят только пары [key, ctid] (по существу). (Ctid по сути является «rowid» - номер страницы кучи и индекс указателя строки кортежа). Таким образом, вы не можете подсчитать строки в таблице, просто пройдя по индексу, потому что вам нужно проверять [xmin, xmax] для каждого кортежа - и это только с данными, в куче.
Вы также можете включить в индекс [xmin, xmax] - время от времени предлагать предложения для этого урожая. Но это раздувает индексы, и для того, чтобы все обновления / удаления были полезными, они должны были бы быть в курсе того, что они были в актуальном состоянии: и это вызывает проблемы, не в последнюю очередь потому, что работа, связанная с обновлением, теперь увеличилась на некоторое количество, умноженное по количеству показателей на столе. В случае значительных индексов, таких как tsvector, или индексов, основанных на дорогостоящих пользовательских выражениях, это может занять некоторое время, а в некоторых неприятных случаях вообще не работает, поскольку строки теперь кажутся живыми в индексе, но мертвыми в куча. И весь смысл этого упражнения должен был состоять в том, чтобы позволить базе данных полагаться исключительно на информацию о живом существовании в индексе, если это возможно. Эта стоимость будет понесена, даже если вы обновляете неиндексированный столбец - то, что команда приложила некоторые усилия для ускорения в 8.3 (кортежи только для кучи).
Полагаю, одной из возможностей было бы пометить индексы как необязательно имеющие [xmin, xmax] - например, пометьте только индекс pkey таким образом. Тогда нужно было бы внести изменения в планировщик, чтобы понять, когда это было преимуществом, - похоже, немало работы.
Таблицы, организованные по индексу, если они работают так, как я считаю, работают в Oracle (и SQL Server, где любая таблица с кластеризованным индексом в основном организована по индексу), работают вместо хранения [key, tuple] в индексе первичного ключа. (и, предположительно, [ключ, pkey] во всех остальных) - нет ctid, нет кучи. Таким образом, «кортеж» будет содержать [xmin, xmax, cminmax, natts, ....] и т. Д., И вы можете удовлетворить «select count (*) from table», просто просканировав индекс. Но это, по сути, то же самое, что сканирование кортежей в куче - они волшебным образом не занимают меньше места, потому что теперь они в «индексе».
AFAICT главная причина организованной по индексу таблицы состоит в том, что небольшая таблица с одним индексом первичного ключа займет 1 страницу вместо 3, а сканирование индекса по первичному ключу может быть немного быстрее. Кажется, я помню, что совет, связанный с Oracle, который мне дали для IOT, заключался в том, что они предназначались для таблиц статических измерений, а не для общего назначения, отчасти из-за затрат на поддержание вторичных индексов (я не думаю, что хранилища Oracle [ key, pkey] во вторичных индексах IOT, а скорее в качестве альтернативного rowid).