=?iso-8859-1?q?Rolf=20=D8stvik?= <rolfostvik@yahoo.no> writes:
> Index Scan using step_result_uut_result_idx on step_result_subset (cost=0.00..563.85 rows=23
> width=4) (actual time=0.069..0.069 rows=0 loops=1)
> Index Cond: (uut_result = $1)
> Filter: (step_parent = 0)
> Total runtime: 0.112 ms
> (4 rows)
Hm, that's interesting. In your original message we have the following
for 7.4's estimate of the same plan step:
-> Index Scan using step_result_uut_result_idx on step_result_subset sr (cost=0.00..74.28 rows=2 width=8) (actual
time=0.149..0.379rows=1 loops=68)
Index Cond: ("outer".id = sr.uut_result)
Filter: (step_parent = 0)
The number-of-matching-rows estimate has gone up by a factor of 10,
which undoubtedly has a lot to do with the much higher cost estimate.
Do you have any idea why that is ... is the table really the same size
in both servers? If so, could we see the pg_stats row for
step_result_subset.uut_result on both servers?
regards, tom lane