Re: speeding up planning with partitions

On 2019/03/08 16:16, Imai, Yoshikazu wrote:
> So I modified the code and did test to confirm memory increasement don't happen. The test and results are below.
>
> [test]
> * Create partitioned table with 1536 partitions.
> * Execute "update rt set a = random();"
>
> [results]
> A backend uses below amount of memory in update transaction:
>
> HEAD: 807MB
> With v26-0001, 0002: 790MB
> With v26-0001, 0002, 0003: 860MB
> With v26-0003 modified: 790MB

Can you measure with v28, or better attached v29 (about which more below)?

> I attached the diff of modification for v26-0003 patch which also contains some refactoring.
> Please see if it is ok.

I like the is_first_child variable which somewhat improves readability, so
updated the patch to use it.

Maybe you know that range_table_mutator() spends quite a long time if
there are many target children, but I realized there's no need for
range_table_mutator() to copy/mutate child target RTEs. First, there's
nothing to translate in their case. Second, copying them is not necessary
too, because they're not modified across different planning cycles. If we
pass to adjust_appendrel_attrs only the RTEs in the original range table
(that is, before any child target RTEs were added), then
range_table_mutator() has to do significantly less work and allocates lot
less memory than before. I've broken this change into its own patch; see
patch 0004.

Thanks,
Amit