Re: Calculate total_table_pages after set_base_rel_sizes()
David Rowley <david.rowley@2ndquadrant.com>
From: David Rowley <david.rowley@2ndquadrant.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Edmund Horner <ejrh00@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2018-10-12T22:35:55Z
Lists: pgsql-hackers
On 12 October 2018 at 23:35, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote: > On 2018/10/11 13:45, Amit Langote wrote: >> On 2018/10/07 17:43, David Rowley wrote: >>> 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. > > Fwiw, I've incorporated David's patch in my own series, so that one of my > patches no longer has the code movement hunks that are in his. I will > post the new version of my patch series like that. Thanks. I'll keep this open here anyway so the change can be considered independently. I think counting pages of pruned partitions is a bug that should be fixed. You can just drop that patch from your set if this gets committed. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
-
Postpone calculating total_table_pages until after pruning/exclusion.
- c6e4133fae1f 12.0 landed