Update Perrformance with nested loop vs. merge-join

Hi,

I just created a new column on a relatively large table (~ 2 mil rows over
400 mb in tablesize) and am trying to populate it from another much smaller
table by using an update query .
The purpose of the query to set a bool flag if the user for the action on
table1 is the last user, as determined from table 2.

The large table has a two column primary key and one of the columns is the
primary key on the smaller table.

My original update query is as follows:

update table1
set lastuser = (table1.user = table2.lastuser)::bool from table2
where table1.pkeycolumn1 = table2.pkey

which has an explain output of

Merge Join (cost=883182.60..1024622.03 rows=6873573 width=89)
Merge Cond: ("outer".pkeycolumn1 = "inner".pkey)
-> Sort (cost=93387.50..94711.01 rows=529404 width=18)
Sort Key: table2.pkey
-> Seq Scan on table2 (cost=0.00..15037.04 rows=529404 width=18)
-> Sort (cost=789795.10..795605.39 rows=2324116 width=81)
Sort Key: table1.pkeycolumn1
-> Seq Scan on table1 (cost=0.00..71900.16 rows=2324116 width=81)

This seems like it *should* be the best query to me, but when I try and run
it it takes forever.
However, when I add a subselect clause to the end to force the planner to
use a nested loop
select on table2, the query runs MUCH faster (1 hour instead of > 10, I
never let it finish)

Here is the query:

update table1
set lastuser = (table1.user = table2.lastuser)::bool from table2
where table1.pkeycolumn1 = table2.pkey
and table1.pkeycolumn1 is in ( select pkey from table3 limit 1000000)

where table1.pkeycolumn1 is a foreign key in table3.pkey. Also, note that
the num of rows in table 3 is *much* less than 1000000.
Also, the limit clause is necessary to force the planner into using the
nested loop. (Aside: Is there a better way to do this inside of a query?)
Here is the explain for the above query:

Hash Join (cost=13863.09..109298.79 rows=51388 width=89)
Hash Cond: ("outer".pkeycolumn1 = "inner".pkey)
-> Seq Scan on table1 (cost=0.00..71900.16 rows=2324116 width=81)
-> Hash (cost=13854.99..13854.99 rows=1621 width=26)
-> Nested Loop (cost=8205.72..13854.99 rows=1621 width=26)
-> HashAggregate (cost=8205.72..8207.72 rows=200 width=8)
-> Limit (cost=0.00..5891.43 rows=185143 width=8)
-> Seq Scan on table3
(cost=0.00..5891.43rows=185143 width=8)
-> Index Scan using table2-pkey-index" on table2 (cost=
0.00..28.14 rows=8 width=18)
Index Cond: ("outer".pkey = table2.pkey)

My only theory up to this point is that it has something to do with how the
tablespace is being cached. I notice that when I use plan 1, my
computer goes through long periods of io and with bursts of processor
activity every minute or so. When I use plan 2, the io sits at about 90%
of my total resource usage while my normal processor usage sits at about
10%. Maybe it keeps trying to cache and resort table2? I don't really
have any idea, but that is my only guess.

If anyone knows why this may be happenning, I would really appreciate it.

Thanks,
Nathan