Re: [HACKERS] UPDATE of partition key

On Sun, Jan 14, 2018 at 6:57 AM, Amit Khandekar <amitdkhan.pg@gmail.com> wrote:
> Even where partitions are present, in the usual case where there are
> no transition tables we won't require per-leaf map at all [1]. So I
> think we should keep mt_per_sub_plan_maps only for the case where
> per-leaf map is not allocated. And we will not allocate
> mt_per_sub_plan_maps when mt_per_leaf_maps is needed. In other words,
> exactly one of the two maps will be allocated.
>
> This is turning out to be close to what's already there in the last
> patch versions: use a single map array, and an offsets array. The
> difference is : in the patch I am using the *same* variable for the
> two maps. Where as, now we are talking about two different array
> variables for maps, but only allocating one of them.
>
> Are you ok with this ? I think the thing you were against was to have
> a common *variable* for two purposes. But above, I am saying we have
> two variables but assign a map array to only *one* of them and leave
> the other unused.

Yes, I'm OK with that.

> Regarding the on-demand map allocation ....
> Where mt_per_sub_plan_maps is allocated, we won't have the on-demand
> allocation: all the maps will be allocated initially. The reason is
> becaues the map_is_required array is only per-leaf. Or else, again, we
> need to keep another map_is_required array for per-subplan. May be we
> can support the on-demand stuff for subplan maps also, but only as a
> separate change after we are done with update-partition-key.

Sure.

> Regarding mt_per_leaf_tupconv_required, I am thinking we can make it a
> bool array, and name it : mt_per_leaf_map_not_required. When it is
> true for a given index, it means, we have already called
> convert_tuples_by_name() and it returned NULL; i.e. it means we are
> sure that map is not required. A false value means we need to call
> convert_tuples_by_name() if it is NULL, and then set
> mt_per_leaf_map_not_required to (map == NULL).

OK.

> Instead of a bool array, we can even make it a Bitmapset. But I think
> access would become slower as compared to array, particularly because
> it is going to be a heavily used function.

It probably makes little difference -- the Bitmapset will be more
compact (which saves time) but involve function calls (which cost
time).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company