Re: speeding up a query

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

In response to

Browse pgsql-general by date

  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