Postgres optimizer choosing wrong index

I'm using postgres 7.4 and having a problem with the query optimizer. Our table,
T, looks like this:

dh int
fh int
nm int
... -- other columns

A typical row is 400-500 bytes.

T has two indexes, idx_df on (dh, fh) and idx_dn on (dh, nm).

My query is

select * from T
where dh = ? and fh = ?

If I run EXPLAIN on this query, (plugging in values 1 and 2 for the variables),
before VACUUM ANALYZE, I get the desired execution plan:

Index Scan using idx_df on T (cost=0.00..4.83 rows=1 width=454)
Index Cond: ((dh = 1) AND (fh = 2))

But after VACUUM ANALYZE:

Index Scan using idx_dn on T (cost=0.00..5.27 rows=1 width=561)
Index Cond: (dh = 1)
Filter: (fh = 2)

Notice that postgres is now using the other index. This behavior is somewhat
dependent on the values plugged in. I ran a query to count dh values:

select dir_hash, count(*) from external_file group by dir_hash;

dh | count
------------+--------
916645488 | 20000
1057692240 | 200000

And if I use 1057692240 in the EXPLAIN, I get the desired plan:

Index Scan using idx_df on external_file (cost=0.00..5.27 rows=1 width=561)
Index Cond: ((dir_hash = 1057692240) AND (fn_hash = 2))

I've tried playing with various cost settings (e.g. random_page_cost), but have
been unable to influence the optimizer's behavior. Rewriting the query as ...
where (dh, fh) = (?, ?) doesn't help.

So a few questions:

- Why would the optimizer ever choose idx_dn over idx_df given that idx_df has
to be more selective?

- Is there any way to force the use of idx_df?

Jack Orenstein

P.S. Yes, I know, 7.4. We're upgrading to 8.3 but we have this problem right now.