That EXPLAIN ANALYZE patch still needs work

Just got this rather surprising result:

regression=# \timing
Timing is on.
regression=# explain analyze select * from tenk1 a join tenk1 b on a.unique1 = b.unique2;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------
Hash Join (cost=825.00..2484.00 rows=10000 width=488) (actual time=250.510..2557.129 rows=10000 loops=1)
Hash Cond: (a.unique1 = b.unique2)
-> Seq Scan on tenk1 a (cost=0.00..458.00 rows=10000 width=244) (actual time=0.084..30.070 rows=10000 loops=1)
-> Hash (cost=458.00..458.00 rows=10000 width=244) (actual time=250.242..250.242 rows=10000 loops=1)
-> Seq Scan on tenk1 b (cost=0.00..458.00 rows=10000 width=244) (actual time=0.019..23.317 rows=10000 loops=1)
Total runtime: 847.855 ms
(6 rows)

Time: 856.179 ms
regression=#

The "Total runtime" is correct AFAICT, which puts the top node's "actual
time" rather far out in left field. This is pretty repeatable on my old
slow HPPA machine. A new Xeon shows less of a discrepancy, but it's
still claiming top node actual > total, which is not right.

I realize that the sampling code can't be expected to be exactly right,
but a factor-of-three error is not acceptable. One of us broke this :-(

regards, tom lane