Re: Calculate total_table_pages after set_base_rel_sizes()
От | David Rowley |
---|---|
Тема | Re: Calculate total_table_pages after set_base_rel_sizes() |
Дата | |
Msg-id | CAKJS1f_VTcHAYRknBuK9guJqQBsQ+cgCbhgUfeDAQR5Za3NdNw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Calculate total_table_pages after set_base_rel_sizes() (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: Calculate total_table_pages after set_base_rel_sizes()
|
Список | 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
В списке pgsql-hackers по дате отправления: