Re: Ok, why isn't it using *this* index?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Paul Tomblin <ptomblin(at)xcski(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Ok, why isn't it using *this* index?
Date: 2001-04-01 20:08:50
Message-ID: 575.986155730@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Paul Tomblin <ptomblin(at)xcski(dot)com> writes:
> waypoint=> explain select * from waypoint where country = 'CANADA';
> NOTICE: QUERY PLAN:

> Seq Scan on waypoint (cost=455.13 rows=6813 width=130)

I take it the majority of rows have country = 'CANADA'? How many rows
in the table all together, anyway? Presumably you're seeing the results
of an estimate that this WHERE clause is too unselective for an index
scan to be profitable. But I can't tell if the rows estimate is any
good or not.

A rule of thumb is that an indexscan will only be used if the index
clauses select no more than a few percent of the rows in the table.
Otherwise the additional I/O to scan the index and to read the table
in nonsequential fashion costs more than a sequential scan does.

> Also, can anybody explain why the "rows=" doesn't correspond to anything
> logical? For instance, in the first one it says "rows=84" even though
> there are 107 matching records, and 71 different states.

ROTFL ... given the thinness of the statistics used to make the
estimate, I'd call rows=84 practically dead on, if the true value
is 107. The system is doing real good here. You can read in the
archives about lots of cases where the estimate is off by a factor
of ten or worse, leading to bad plan choices. This estimate is
plenty close enough to arrive at a reasonable plan.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Paul Tomblin 2001-04-01 20:10:29 Re: Ok, why isn't it using *this* index?
Previous Message Daniel ?erud 2001-04-01 20:06:32 Re: Re: Dissapearing indexes, what's that all about?