10% selectivity is the minimum selectivity necessary for a b-tree index to be helpful. That's probably on the high side. Suppose that records are stored in 8KB

10% selectivity is the minimum selectivity necessary for a b-tree index to be helpful. That's probably on the high side. Suppose that records are stored in 8KB pages (which is probably too small for a modern system, but nevermind), the selectivity of the scan is 10%, the records that satisfy the scan are randomly distributed over the pages, each page holds, say, 40 records (which is conservative, even for small 8KB pages), and we're considering scanning a secondary index[1]. That means that a typical page in the heap has 4 matching records, which means we are very likely to have to read every page in the heap anyway. Worst still, the order in which the index scan returns results is unlikely to correlate with the physical storage order of the heap pages, which means that the 4 IOs per page are going to be random, not sequential. Add to that, in a scan of a secondary index, you need to read both the index page and the pointed-to heap page, which is an additional I/O (compared to a sequential scan of the heap). So it's easy to construct a realistic scenario when you wouldn't want to use a secondary index when the scan selectivity is "only" 10%. [1] And that an index-only plan can't be used: i.e. we need to fetch the pointed-to heap page.