On 6 October 2018 at 18:20, Edmund Horner <ejr...@gmail.com> wrote: > David Rowley said: >> 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.
Thanks for looking at this and testing it too. The primary purpose of this patch was step 1 in delaying the creation of RangeTblEntrys for partitions until after partition pruning has taken place. The code I had to do this caused problems around the total_table_pages calculation due to the lack of RangeTblEntry for the partitions at the time it was being calculated. But regardless of that, I still believe where we currently calculate this number is subtlely broken as it counts all partitions, even ones that will later be pruned, thus decreasing the likelihood of an index being used as random_page_cost would be applied to a higher number of index pages. Amit Langote has since posted a patch to delay the RangeTblEntry creation until after pruning. His patch happens to also move the total_table_pages calculation, but I believe this change should be made as an independent commit to anything else. I've kept it in the commitfest for that reason. > Basically I think it's ready for a committer to look at. Should I > update the CF entry? That sounds good, please do. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
