From: | Masaru Sugawara <rk73(at)sea(dot)plala(dot)or(dot)jp> |
---|---|
To: | "Thomas T(dot) Thai" <tom(at)minnesota(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: help with getting index scan |
Date: | 2002-03-06 17:35:02 |
Message-ID: | 20020307023431.DEC1.RK73@sea.plala.or.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 6 Mar 2002 08:42:43 -0600 (CST)
"Thomas T. Thai" <tom(at)minnesota(dot)com> wrote:
> On Wed, 6 Mar 2002, Masaru Sugawara wrote:
> [...]
> > That's not bat, I guess. The query below is a try to manage to get
> > a pattern like this:
> >
> > -> Nested Loop
> > -> Index Scan using phone_cat_nameftx_idx on phone_cat pc
> > -> Index Scan using phone_cat_address_cid_key on phone_cat_address pca
>
> the query below still results in a seq scan:
> ...
> -> Seq Scan on phone_cat_address pca
> (cost=0.00..5843.01 rows=336701 width=8)
> (actual time=0.97..2875.06 rows=336701 loops=1)
> -> Hash (cost=43.58..43.58 rows=11 width=4)
> (actual time=3.91..3.91 rows=0 loops=1)
It's a pity that the query use no index on phone_cat_address.
> ...
> Total runtime: 5240.28 msec
>
> something is not right about with the planner. using my original query and
> with seqscan off, i can get the query to drop to around 600 ms. can't
> understand why it would choose to use seqscan on phone_cat_address.
Since phone_cat_address isn't limited by a WHERE cluse, etc., most of its
rows will be selected. Therefore the planner seems to judge that a
sequential scan is better/faster than an index scan.
Regards,
Masaru Sugawara
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas T. Thai | 2002-03-06 18:11:17 | Re: help with getting index scan |
Previous Message | David Griffiths | 2002-03-06 17:30:39 | Re: Problems with unconstrained join |