So, since it thinks it needs to read 1/412th of the table is the reason why the query planner chooses to use the primary key index instead of the callingpartynumber index, like it does in the first 3 cases? I'm curious as to why it says "rows=41212". Is that the estimate of the number of rows that meet the filter condition? Where does that come from?
I haven't heard of raising the statistics target, so I'll read up on that. A few days ago, all 4 cases were responding equally fast. I had been messing around with the postgres settings, and I went and dropped all of the indexes and recreated them just to see what would happen. I wouldn't think that recreating the indexes would cause case 4 to go slow, but that's the symptom I am seeing now. Should I be running analyze on a table after it has been reindexed?