Re: Calculate total_table_pages after set_base_rel_sizes()
Amit Langote <amitlangote09@gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>,
Edmund Horner <ejrh00@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2018-10-12T22:43:55Z
Lists: pgsql-hackers
On Sat, Oct 13, 2018 at 7:36 David Rowley <david.rowley@2ndquadrant.com> wrote: > 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. Yeah, that was my plan anyway. Thanks, Amit > >
Commits
-
Postpone calculating total_table_pages until after pruning/exclusion.
- c6e4133fae1f 12.0 landed