David Rowley said: > I believe that we should be delaying the PlannerInfo's > total_table_pages calculation until after constraint exclusion and > partition pruning have taken place. Doing this calculation before we > determine which relations we don't need to scan can lead to > incorrectly applying random_page_cost to too many pages processed > during an Index Scan. > > We already don't count relations removed by join removals from this > calculation, so counting pruned partitions seems like an omission. > > The attached patch moves the calculation to after set_base_rel_sizes() > is called and before set_base_rel_pathlists() is called, where the > information is actually used. > > I am considering this a bug fix, but I'm proposing this for PG12 only > as I don't think destabilising plans in the back branches is a good > idea. I'll add this to the September commitfest.
I played with the new patched today with a set of large partitions. It seems to work, though the effect is subtle. The expected behaviour of index_pages_fetched is a bit hard to fathom when the cache share pushes it between cases A,B and C of the formula, but that's not really down to this patch. Basically I think it's ready for a committer to look at. Should I update the CF entry? Edmund
