This is quite a common query (pardon the pun! :-) ) from people running queries which perform full table scans (FTS), when the poster feels that the system should make use of the index(es).
Basically, it boils down to the explanation given here. If the tables are so small, the optimiser will say that "it's not worth the bother of going to the index, doing a lookup and then fetching the data, instead, I'll just slurp in all the data and pick out what I need", i.e. perform an FTS.
[EDIT in answer to @txsing's comment]
For an MVCC (multi-version concurrency control) database, you have to traverse every record for a count at a given moment - that's why, for example, a COUNT(*) is much more expensive for MySQL's InnoDB rather than MyISAM.
An excellent explantion (for PostgreSQL) is available here. The guy who wrote this post is a "major contributor" to PostgreSQL (thanks to @dezso for leading me to that post).
In this case, it's doing an Index Scan. As best as I know, the difference between an Index scan and a Bitmap Index/Heap Scan is that the former will read pages in the order defined by the index, while the latter will create a bitmap of pages to read (possibly from multiple indexes), order the results, and read them in [heap] order.
Correct.
There are also index-only scans, where the index is read to satisfy the query directly, and there's no heap fetch for most of the index pages read. Heap fetches can still be required if the system can't be sure the pages are visible to all transactions, so it's like an index scan with a shortcut.
It seems to me that in both cases, one would need to read the pages of the index to actually determine the resulting data pages to read.
Correct.
However, in the "Index Scan" the line for "Buffers" has 160 pages, which based on my other tests is the number of pages of actual data, and doesn't include the 32 pages I saw above in the Bitmap Index Scan for the index itself.
I think this is the misunderstanding. That line will be the sum of pages read from the index and from the heap. Not all index pages, and not all heap pages, will need to be read.
Another important note is that the "buffers" metrics, like other metrics in an EXPLAIN, are cumulative: the number of pages read in the parent node includes that of the child nodes. Thus the 160 buffers hit include the index reads. In actuality, only 128 pages were read from the heap in both of the final cases.
Best Answer
An Index Only Scan (not "query") is a step in an execution plan that retrieves data only from an index and does not require a lookup to the actual table data.
This optimization can only be used if there is an index that contains all columns that are needed by the query. If such an index exists, that index is called a "covering index" because it "covers" all needed columns.
Or to put it the other way round: only if there is a covering index, the query optimizer can use an Index Only Scan.