Help understanding how indexes are used by the query optimizer

Hi,

We're having difficulty understanding why PostgreSQL (6.5.3 on Red Hat Linux
6.0) won't use a primary key index.

Here's the SQL statement:

select users.userid, phone.phone, phone.phonetype, phone.phonenumber
from users, phone
where
users.person = personphone.person AND
personphone.phone = phone.phone


Here's the phone table:

+----------------------------------+----------------------------------+-----
--+
|              Field               |              Type                |
Length|
+----------------------------------+----------------------------------+-----
--+
| phone                            | int4 not null                    |
4 |
| phonetype                        | int4 not null                    |
4 |
| phonenumber                      | varchar() not null               |
35 |
| lastuser                         | varchar()                        |
30 |
| lastmodified                     | datetime                         |
8 |
| lastaction                       | varchar()                        |
30 |
+----------------------------------+----------------------------------+-----
--+

Here's the index for PHONE:

+----------------------------------+----------------------------------+-----
--+
|              Field               |              Type                |
Length|
+----------------------------------+----------------------------------+-----
--+
| phone                            | int4                             |
4 |
+----------------------------------+----------------------------------+-----
--+

Here's the output from EXPLAIN

Hash Join  (cost=1247.17 rows=14779 width=36)
  ->  Seq Scan on phone  (cost=668.41 rows=14770 width=20)
  ->  Hash  (cost=23.58 rows=1811 width=16)
        ->  Nested Loop  (cost=23.58 rows=1811 width=16)
              ->  Seq Scan on users  (cost=1.36 rows=11 width=8)
              ->  Index Scan using personphone_fkey on personphone
(cost=2.02 rows=1810 width=8)

The question is, why will PostgreSQL not use the primary key index that is
defined for the PHONE table. It appears from this output that it is doing a
full-table sequential scan of 14,770 records.