Re: Why is query selecting sequential? - Mailing list pgsql-performance

From Tom Lane
Subject Re: Why is query selecting sequential?
Date
Msg-id 17425.1076136714@sss.pgh.pa.us
Whole thread Raw
In response to Re: Why is query selecting sequential?  (Karl Denninger <karl@denninger.net>)
Responses Re: Why is query selecting sequential?
List pgsql-performance
Karl Denninger <karl@denninger.net> writes:
> akcs=> explain analyze select forum, (replied > (select lastview from forumlog where forumlog.login='genesis' and
forumlog.forum='General'and number=post.number)) as newflag, * from post where forum = 'General' and toppost = 1 order
bypinned desc, replied desc;                
>                                                          QUERY PLAN
      
>
----------------------------------------------------------------------------------------------------------------------------
>  Sort  (cost=28.41..28.42 rows=6 width=218) (actual time=0.677..0.698 rows=5 loops=1)
>    Sort Key: pinned, replied
>    ->  Index Scan using post_toppost on post  (cost=0.00..28.33 rows=6 width=218) (actual time=0.403..0.606 rows=5
loops=1)
>          Index Cond: ((forum = 'General'::text) AND (toppost = 1))
>          SubPlan
>            ->  Seq Scan on forumlog  (cost=0.00..1.18 rows=1 width=8) (actual time=0.015..0.027 rows=1 loops=5)
>                  Filter: ((login = 'genesis'::text) AND (forum = 'General'::text) AND (number = $0))
>  Total runtime: 0.915 ms
> (8 rows)

As noted elsewhere, the inner subplan will not switch over to an
indexscan until you get some more data in that table.  Note however that
the subplan is only accounting for about 0.13 msec (0.027*5) so it's not
the major cost here anyway.  The slow part seems to be the indexed fetch
from "post", which is taking nearly 0.5 msec to fetch five rows.

            regards, tom lane

pgsql-performance by date:

Previous
From: Josh Berkus
Date:
Subject: Re: 7.3 vs 7.4 performance
Next
From: Tom Lane
Date:
Subject: Re: 7.3 vs 7.4 performance