Re: Why is query selecting sequential?

Поиск
Список
Период
Сортировка
От Karl Denninger
Тема Re: Why is query selecting sequential?
Дата
Msg-id 20040207101052.A15045@Denninger.Net
обсуждение исходный текст
Ответ на Re: Why is query selecting sequential?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Why is query selecting sequential?  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-performance
On Sat, Feb 07, 2004 at 01:51:54AM -0500, Tom Lane wrote:
> 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

Ok...

BTW, the other posted "cleaner" model doesn't work for me.  If there is NO
row in the subtable that matches, the other version returns nothing (which
makes sense since the initial select fails to match any rows as one of the
things its trying to match is missing.)

I do need a return even if the log row is missing (and it WILL be, for a
first visit to that particular item in the table by a particular user)

--
--
Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist
http://www.denninger.net    Tired of spam at your company?  LOOK HERE!
http://childrens-justice.org    Working for family and children's rights
http://diversunion.org        LOG IN AND GET YOUR TANK STICKERS TODAY!

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: 7.3 vs 7.4 performance
Следующее
От: "Bruno BAGUETTE"
Дата:
Сообщение: RE : RE : Increase performance of a UNION query that thakes 655.07 msec to be runned ?