Tom Lane skrev:
> 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
>
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