Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-sql by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group