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.