Marcus Engene <mengpg2@engene.se> writes:
> Should it take 2.5s to sort these 442 rows?
> Limit (cost=54.40..54.43 rows=12 width=8) (actual
> time=2650.254..2651.093 rows=442 loops=1)
> -> Sort (cost=54.40..54.43 rows=12 width=8) (actual
> time=2650.251..2650.515 rows=442 loops=1)
> Sort Key: calc_rating
> -> Index Scan using apa_item_fts on apa_item ai
> (cost=0.00..54.18 rows=12 width=8) (actual time=61.261..2649.045
> rows=442 loops=1)
> Index Cond: (idxfti @@ '''kca0304'''::tsquery)
> Filter: (status = 30)
> Total runtime: 2651.659 ms
It's not the sort that's taking 2.5s --- the sort looks to be taking
about a millisec and a half. The indexscan is eating the other 2649
msec. The question that seems to be interesting is what's the
difference between the contexts of your two queries, because they
sure look like the indexscans were the same. Maybe the second one
is merely benefiting from the first one having already sucked all the
data into cache?
regards, tom lane
