On Wed, Jan 18, 2017 at 2:12 PM, Melvin Davidson <melvin6925@xxxxxxxxx> wrote:
On Wed, Jan 18, 2017 at 3:06 PM, Merlin Moncure <mmoncure@xxxxxxxxx> 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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I never got an answer to my question.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?
merlin
