Tom Lane skrev:
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
Yes indeed you are completely right! Both queries take about the same when
run after the other. And I just made a fool of myself with an optimizing
idea I
had...
Sorry for the noise and thanks for your answer!
Best regards,
Marcus
