Query planner cost estimate less than the sum of its parts?

So, we had a query run accidentally without going through the right checks
to ensure that it had the right limits in a where clause for our table
partitioning, resulting in an attempt to scan TB's of data.

Obviously, we fixed the query, but the curious result is this explain plan
(shortened, in full form its ~3500 lines long). A true cost estimate of ~ 4
million isn't a big deal on this server. It is plainly wrong... wouldn't a
nested loop of this sort estimate at least 128266*4100644 for the cost? Or
something on that order of magnitude?
Certainly, a cost estimate that is ... LESS than one of the sub sections of
the query is wrong. This was one hell of a broken query, but it at least
should have taken an approach that was not a nested loop, and I'm curious if
that choice was due to a bad estimate here.

Nested Loop IN Join (cost=0.00..3850831.86 rows=128266 width=8)
Join Filter: ((log.p_p_logs.s_id)::text = (log.s_r_logs.s_id)::text)
-> Append (cost=0.00..6078.99 rows=128266 width=46)
-> Seq Scan on p_p_logs (cost=0.00..1.01 rows=1 width=14)
Filter: ((date >= '2008-10-27'::date) AND (sector = 12))
-> Seq Scan on p_p_logs_012_2008_10_27 p_p_logs
(cost=0.00..718.22 rows=15148 width=46)
Filter: ((date >= '2008-10-27'::date) AND (sector = 12))
[ Snipped ~ 10 more tables]

-> Append (cost=0.00..4100644.78 rows=29850181 width=118)
-> Seq Scan on s_r_logs (cost=0.00..1.01 rows=1 width=14)
Filter: log.s_r_logs.source
-> Seq Scan on s_r_logs_002_2008_10_01 s_r_logs (cost=0.00..91.00
rows=1050 width=33)
Filter: p_log.s_r_logs.source
-> Seq Scan on s_r_logs_002_2008_10_02 s_r_logs (cost=0.00..65.00
rows=750 width=33)
[ Snipped ~1500 tables of various sizes ]