Re: any way to use indexscan to get last X values

Shridhar Daithankar <shridhar_daithankar@persistent.co.in>

From: "Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>
To: pgsql-performance@postgresql.org
Date: 2003-06-16T06:15:52Z
Lists: pgsql-performance
On 16 Jun 2003 at 0:37, Tomaz Borstnar wrote:
> 
> krtjavendan34=>  EXPLAIN ANALYZE SELECT thread, modifystamp, count(id) AS 
> tcount,abstime(modifystamp) AS latest, max(id) as maxid FROM tjavendan 
> WHERE approved='Y'  GROUP BY modifystamp, thread ORDER BY modifystamp desc, 
> thread desc limit 40;
>                                                                                 QUERY 
> PLAN
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>   Limit  (cost=0.00..97.13 rows=40 width=12) (actual time=1.07..48.71 
> rows=40 loops=1)
>     ->  Aggregate  (cost=0.00..20947.38 rows=8626 width=12) (actual 
> time=1.05..48.23 rows=41 loops=1)
>           ->  Group  (cost=0.00..20516.06 rows=86265 width=12) (actual 
> time=0.35..42.25 rows=843 loops=1)
>                 ->  Index Scan Backward using tjavendan_modstamp_thrd on 
> tjavendan  (cost=0.00..20084.73 rows=86265 width=12) (actual 
> time=0.34..31.29 rows=844 loops=1)
>                       Filter: (approved = 'Y'::bpchar)
>   Total runtime: 50.20 msec
> (6 rows)
> 
> Used to be between 5800 and 6741 msec before this patch!

Good that the patch works for you. But as I see there is an improvement in 
plan. Not nitpicking but what does actual performance difference between system 
before patch and after patch?

Bye
 Shridhar

--
QOTD:	"In the shopping mall of the mind, he's in the toy department."