> Index scans imply extra disk seeks to fetch the index. This is no longer true in this generality, because since PostgreSQL 9.2 there are also index-only scan

> Index scans imply extra disk seeks to fetch the index. This is no longer true in this generality, because since PostgreSQL 9.2 there are also index-only scans. Those scans take the data directly from the index, without going through the original rows at all. Of course, this works only under certain conditions. See also: http://michael.otacoo.com/postgresql-2/postgresql-9-2-highlight-index-only-scans/ http://michael.otacoo.com/postgresql-2/postgresql-9-2-highli... http://www.postgresql.org/docs/9.2/static/index-scanning.html http://www.postgresql.org/docs/9.2/static/index-scanning.htm... "If the index stores the original indexed data values (and not some lossy representation of them), it is useful to support index-only scans, in which the index returns the actual data not just the TID of the heap tuple. This will only work if the visibility map shows that the TID is on an all-visible page; else the heap tuple must be visited anyway to check MVCC visibility. But that is no concern of the access method's."