"Jan-Philipp 'Thefly' Reining" <jpr@turtle-entertainment.de> writes:
> Index Scan using ranking_ttm_slots_key on ttm_slots s (cost=0.00..191.06
> rows=8 width=62) (actual time=0.26..0.83 rows=7 loops=1)
> Total runtime: 1.02 msec
> Seq Scan on ttm_slots s (cost=0.00..1823.64 rows=7949 width=62) (actual
> time=0.08..361.12 rows=9840 loops=1)
> Total runtime: 379.47 msec
I kinda think the planner made the right choice here. Assuming that it
will take 1400 times longer to select 1400 times more rows via
indexscan, the indexed plan for the second query would take something
upwards of 1100 msec.
You could check it by "set enable_seqscan = off" and then repeat the
second EXPLAIN ANALYZE.
You will also find that as you narrow the range of the range query,
the planner will eventually prefer an indexscan. Ideally it will
switch over somewhere around the point where the runtimes are actually
equal ;-) ... but I'd be ecstatic if it gets it right within a factor of
2.
Beware of disk cache effects when doing this sort of test --- repeating
the identical query often gives a lower actual runtime on second and
subsequent tests.
regards, tom lane
