Re: Use of index in 7.0 vs 6.5

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ryan Bradetich <ryan_bradetich(at)hp(dot)com>
Cc: pgsql-sql(at)postgreSQL(dot)org
Subject: Re: Use of index in 7.0 vs 6.5
Date: 2000-05-25 03:12:32
Message-ID: 19295.959224352@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Ryan Bradetich <ryan_bradetich(at)hp(dot)com> writes:
> I am in the process of transitioning from postgreSQL 6.5.3 to
> postgreSQL 7.0. I ran into an issue where a sequential scan
> is being choosen on postgreSQL 7.0 where an index scan was
> choosen on postgreSQL 6.5.3.

Since you're complaining, I assume the seqscan is slower ;-).
But you didn't say how much slower --- what are the actual timings?

Basically what's going on here is that we need to tune the fudge-factor
constants in the cost model so that they have something to do with
reality on as wide a variety of systems as possible. You did an
excellent job of showing the estimates the planner computed --- but
what we really need here is to see how those relate to reality.

> I do not understand why the planner would choose a seqscan over the
> index scan because 6704/4,630,229 is ~ 0.15%.

I'm a bit surprised too. What is the average tuple width on this table?
(Actually, probably a better question is how many pages and tuples
are in the relation according to its pg_class entry. Try "select * from
pgclass where relname = 'medusa'".)

regards, tom lane

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Ryan Bradetich 2000-05-25 03:57:25 Re: Use of index in 7.0 vs 6.5
Previous Message Tom Lane 2000-05-25 02:59:58 Re: possible bug with group by?