Marcus Engene <mengpg2@xxxxxxxxx> 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
