From: | Marcus Engene <mengpg2(at)engene(dot)se> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: speeding up a query |
Date: | 2007-04-04 03:41:28 |
Message-ID: | 46131E68.70207@engene.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane skrev:
> Marcus Engene <mengpg2(at)engene(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-04-04 03:50:51 | Re: Using MS Access front-end with PG] |
Previous Message | Marcus Engene | 2007-04-04 03:34:04 | Re: speeding up a query |