Re: Optimizing query - Mailing list pgsql-general

From Tom Lane
Subject Re: Optimizing query
Date
Msg-id 25298.1124113567@sss.pgh.pa.us
Whole thread Raw
In response to Re: Optimizing query  (Poul Møller Hansen <freebsd@pbnet.dk>)
Responses Re: Optimizing query  (Poul Møller Hansen <freebsd@pbnet.dk>)
Question about the NAME type used in pg_proc and pg_class  (Tony Caduto <tony_caduto@amsoftwaredesign.com>)
List pgsql-general
=?ISO-8859-1?Q?Poul_M=F8ller_Hansen?= <freebsd@pbnet.dk> writes:
> explain analyze SELECT * FROM my.table WHERE node = '10' ORDER BY node,
> id DESC LIMIT 1
>                                                                  QUERY
> PLAN
>
--------------------------------------------------------------------------------------------------------------------------------------------
>  Limit  (cost=22638.36..22638.36 rows=1 width=246) (actual
> time=3.001..3.007 rows=1 loops=1)
>    ->  Sort  (cost=22638.36..22652.59 rows=5691 width=246) (actual
> time=2.984..2.984 rows=1 loops=1)
>          Sort Key: node, id
>          ->  Index Scan using node_date on table  (cost=0.00..21898.65
> rows=5691 width=246) (actual time=0.077..1.852 rows=62 loops=1)
>                Index Cond: ((node)::text = '10'::text)
>  Total runtime: 3.127 ms

You're not there yet: you want what Richard said, namely

explain analyze SELECT * FROM my.table WHERE node = '10' ORDER BY node DESC,
id DESC LIMIT 1

There shouldn't be any Sort in the plan, just the indexscan and Limit.
The plan above is going to suck if there are a lot of rows with node = '10'.

            regards, tom lane

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: hash-join forgets tuples
Next
From: Sebastian Freundt
Date:
Subject: Re: hash-join forgets tuples