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
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
