On 2018/10/07 17:43, David Rowley wrote: > 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.
Yeah, if this patch is a win independent of the other project of delaying partition RTE creation, which seems to be true, I think we should go ahead with applying this patch. >> Basically I think it's ready for a committer to look at. Should I >> update the CF entry? > > That sounds good, please do. +1 Thanks, Amit
