Re: Odd problem with performance in duplicate database

Josh Berkus <josh@agliodbs.com> 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=0loops=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=0loops=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