Josh Berkus <[EMAIL PROTECTED]> writes:
> My reading is that the case is "borderline";
Well, clearly the planner is flipping to a much less desirable plan, but
the core estimation error is not borderline by my standards. In the
live DB we have this subplan:
-> Nested Loop (cost=0.00..7.41 rows=1 width=12) (actual time=0.01..0.02 rows=1
loops=856)
-> Index Scan using trial_groups_pkey on trial_groups (cost=0.00..3.49 rows=1
width=4) (actual time=0.01..0.01 rows=0 loops=856)
-> Index Scan using idx_cases_tgroup on cases (cost=0.00..3.92 rows=1 width=8)
(actual time=0.02..0.04 rows=4 loops=133)
In the test DB, the identical subplan is estimated at:
-> Nested Loop (cost=0.00..81.53 rows=887 width=12) (actual time=0.03..0.04 rows=1
loops=855)
-> Index Scan using trial_groups_pkey on trial_groups (cost=0.00..3.49 rows=1
width=4) (actual time=0.02..0.02 rows=0 loops=855)
-> Index Scan using idx_cases_tgroup on cases (cost=0.00..77.77 rows=43 width=8)
(actual time=0.03..0.07 rows=6 loops=133)
and that factor of 887 error in the output rows estimate is what's
driving all the outer plan steps to make bad choices.
The "trial_groups_pkey" estimate is the same in both databases,
so it's presumably a problem with estimating the number of
matches to a "trial_groups" row that will be found in "cases".
This is dependent on the pg_stats entries for the relevant
columns, which I'm still hoping to see ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
