On Wed, Jan 18, 2017 at 3:06 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
On Wed, Jan 18, 2017 at 1:04 PM, Ravi Tammineni <rtammineni@partner.aligntech.com> wrote: > Hi Chris, > > Here is the query and execution plan in 9.5 and 9.6.
Can you verify tblpuorderstatus and tblpuorderstatushistory have all indexes accounted for on both servers? It seems incredible server would prefer wading through 11M records to 1298 nestloop. I'm curious what plans you get if you try playing around with:
set enable_seqscan=false; set enable_hashjoin=false;
...but I think we have two possibilities here: 1. schema mismatch 2. planner bug merlin
Have you verified that postgresql.conf is the same of both 9.5 & 9.6?
This is not verified, but I can't think of an influential planner variable that would push planner cost from 2600 to millions; abrupt increase in plan cost roles out a knife edge plan choice and the statistic look relatively correct on rows. Unless planner choices are disabled in postgresql.conf, this suggests something is preventing planner from choosing a particular kind of plan for this query, which is suggesting bug to me.
OP, if you want to contribute to the investigation of fix, "git bisect" is the way to proceed...is that feasible?
