Hi, Here is a snapshot of the code I'm fiddling with at the moment which actually tracks how much time is spent executing which parts of the query plan. It still has some issues but it has restored my faith in Postgres' estimation system. It's within an order of magnitude in the tests I've done and that much better than before. Before anyone complains that it uglifies explain.c, I know. I just havn't decided if it's query that happens to output statistics, an explain that happens to run the query or something new altogether. It's against latest CVS. I'm pretty sure it handles query interleaving fine. Things known to be wrong: * Certain types of nodes seem to go wrong. Group is miscounted and one node got skipped completely. It does seem to count the number of rows processed correctly, which is possibly the most important. All times are in milliseconds. Example output (wide): Aggregate (cost=51479.55..51507.07 rows=550 width=48) actual (time=25278.68..26080.44 rows=156 loops=1) -> Group (cost=51479.55..51493.31 rows=5503 width=48) actual (time=25278.64..25278.65 rows=2 loops=1) -> Sort (cost=51479.55..51479.55 rows=5503 width=48) actual (time=25278.62..25281.77 rows=2029 loops=1) -> Hash Join (cost=676.79..51137.62 rows=5503 width=48) actual (time=3618.79..25259.53 rows=2029 loops=1) -> Seq Scan on dailycalls (cost=0.00..50150.07 rows=32262 width=12) actual (time=61.91..24831.90 rows=41045 loops=1) -> Hash (cost=671.31..671.31 rows=2193 width=36) actual (time=146.56..146.56 rows=0 loops=1) -> Merge Join (cost=260.50..671.31 rows=2193 width=36) actual (time=37.37..131.11 rows=1330 loops=1) -> Index Scan using clines_cid on clines (cost=0.00..364.36 rows=6308 width=20) -> Sort (cost=260.50..260.50 rows=1305 width=16) actual (time=36.91..38.40 rows=1337 loops=1) -> Seq Scan on company (cost=0.00..192.94 rows=1305 width=16) actual (time=0.10..22.70 rows=1314 loops=1) I'm still getting a lot of debug messages so there is still some work to do. Any comments? (Oops, just thought of one issue: Merge Join will not exhaust it's subnodes because it can stop early). http://svana.org/kleptog/pgsql/timing-explain.patch -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > It would be nice if someone came up with a certification system that > actually separated those who can barely regurgitate what they crammed over > the last few weeks from those who command secret ninja networking powers. ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html