Re: speeding up a query

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marcus Engene <mengpg2(at)engene(dot)se>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: speeding up a query
Date: 2007-04-04 03:29:57
Message-ID: 15161.1175657397@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Marcus Engene 2007-04-04 03:34:04 Re: speeding up a query
Previous Message Joshua D. Drake 2007-04-04 03:22:31 Re: Using MS Access front-end with PG]