performance on update table from a join

I am updating a large (1M+) table from a join.  There is no question the
table has to be sequencially scanned. But, I am surprised that Postgres
would perform the join in order to do the update.

My take is that it should lookup in the "rs" table for a match and then
from this reduced set lookup the "routes" table.

Since it is performing an update, it is fair to assume that there will
be only one record from "routes" that will match the where clause. So,
why waste resources performing the join first?

Or maybe I am not reading the query plan correctly...

THX


nsd=# explain update c set newroute = r.route, route = r.routeno, street
= trim( lpad( r.seqno, 4, '0')), exchangeno = r.exchangeno
nsd-# from routes r, rs s where ( c.stname, c.municipality) =
(s.oldstname, s.oldmuni) and
nsd-# (s.exchangeno, s.stname, s.municipality) = ( r.exchangeno,
r.street, r.municipality) and
nsd-# r.fromno <= c.civic and c.civic <= r.tono and (r.parity =
c.civic%2 or r.parity = -1);
NOTICE:  QUERY PLAN:
Hash Join  (cost=109.44..118460.53 rows=1 width=857) ->  Seq Scan on c  (cost=0.00..112409.04 rows=1156604 width=519)
-> Hash  (cost=109.44..109.44 rows=1 width=338)       ->  Merge Join  (cost=0.00..109.44 rows=1 width=338)
-> Index Scan using routes_str_mun on routes r 
 
(cost=0.00..52.00 rows=1000 width=152)             ->  Index Scan using rs_stname on rs s  (cost=0.00..52.00
rows=1000 width=186)
EXPLAIN