* Usually I've been able to force query plans by disabling whole operations for a session, such as disallowing "sort" to make it use an index. The real fix in this case, for example, was to use CLUSTER to re-order data on disk, so the correlation statistic was close to 1 and postgres wanted to use the index instead of table scan + sort.
And here we see the benefit of clustered indices, á la MySQL. Assuming, of course, your PK is k-sortable.
> In InnoDB, each record in a secondary index contains the primary key columns for the row, as well as the columns specified for the secondary index.
I think that unless you're only doing table scans, or your rows are inserted in no discernible order, you should see a speedup. If the latter though, then yes of course, page jumps are page jumps.
Happy to test this to find out.
SET enable_seqscan = OFF;
If you're on an SSD and not a spinning disk, or have a lot of memory and can expect it to all be cached, there's a separate setting you can change to adjust the random access penalty - see random_page_cost on https://www.postgresql.org/docs/current/runtime-config-query...