On 10/8/17 3:02 PM, Jim Nasby wrote:
-> Index Scan using bdata_filed_departuretime on bdata_forks
(cost=0.57..50807.51 rows=1 width=36) (actual time=979.381..3207.777
rows=508 loops=1)
-> Index Scan using bdata_filed_departuretime on bdata_forks
(cost=0.57..14894236.06 rows=1 width=36) (actual
time=892.664..3025.653 rows=508 loops=1)
I think the reason it's discarding the preferable plan is that, with this
huge increment in the estimated cost getting added to both alternatives,
the two nestloop plans have fuzzily the same total cost, and it's picking
the one you don't want on the basis of some secondary criterion.
Great question... the only thing that sticks out is the coalesce(). Let
me see if an analyze with a higher stats target changes anything. FWIW,
the 9.6 database is copied from the 9.4 one once a week and then
pg_upgraded. I'm pretty sure an ANALYZE is part of that process.
Turns out that analyze is the 'problem'. On the 9.4 database, pg_stats
shows that the newest date in filed_departuretime is 3/18/2017, while
the 9.6 database is up-to-date. If I change the query to use 2/9/2018
instead of 7/20/2017 I get the same results.
So, the larger cost estimate is theoretically more correct. If I set
random_page_cost = 1 I end up with a good plan.
--
Jim C. Nasby, Data Architect j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
