Re: help with getting index scan

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

In response to

Responses

Browse pgsql-general by date

  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