I'm giving 9.2-beta2 a test simulating a production workflow.
Everything looks OK except the speed. Most (all?) queries take about
five to six times as long as they do with 9.1.
The configurations are essentially the same, the query plans are the same.
A (hot) example, pulled semi-randomly from a run, with the names mangled
to protect the innocent:
===================================== 9.1 =====================================Nested Loop (cost=0.00..26.92 rows=1
width=28)(actual time=0.114..0.514 rows=19 loops=1) -> Index Scan using ms_pkey on ms msg (cost=0.00..26.03 rows=1
width=20)(actual time=0.026..0.207 rows=19 loops=1) Index Cond: ((ms_id >= 407) AND (ms_id <= 435) AND (mb_id =
50222)) Filter: (status = ANY ('{0,1,2}'::integer[])) -> Index Scan using ph_pkey on ph pm (cost=0.00..0.87
rows=1width=16) (actual time=0.010..0.010 rows=1 loops=19) Index Cond: (id = msg.ph_id)Total runtime: 0.605 ms
===================================== 9.2 =====================================Nested Loop (cost=0.00..30.12 rows=1
width=28)(actual time=0.439..2.540 rows=19 loops=1) -> Index Scan using ms_pkey on ms msg (cost=0.00..29.18 rows=1
width=20)(actual time=0.155..1.157 rows=19 loops=1) Index Cond: ((ms_id >= 407) AND (ms_id <= 435) AND (mb_id =
50222)) Filter: (status = ANY ('{0,1,2}'::integer[])) -> Index Scan using ph_pkey on ph pm (cost=0.00..0.93
rows=1width=16) (actual time=0.053..0.054 rows=1 loops=19) Index Cond: (id = msg.ph_id)Total runtime: 2.752 ms
All of the tables and indices for the run in question fit into ram. The
effective cache, work mem, costs, etc were optimized in 9.0, and kept
for 9.1 and the beta. That the plans are the same suggests that isn't
the problem, yes?
I think I recall mention from a previous beta (but goog isn't helping me
confirm) that there is some extra debugging or such enabled in the betas.
If so, and if turning that off would provide a better comparison, where
in the src should I look?
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6