Re: Optimize planner memory consumption for huge arrays

On Mon, Sep 4, 2023, at 3:37 PM, Dilip Kumar wrote:
> On Mon, Sep 4, 2023 at 11:58 AM Lepikhov Andrei
> <a(dot)lepikhov(at)postgrespro(dot)ru> wrote:
>>
>> Hi, hackers,
>>
>> Looking at the planner behaviour with the memory consumption patch [1], I figured out that arrays increase memory consumption by the optimizer significantly. See init.sql in attachment.
>> The point here is that the planner does small memory allocations for each element during estimation. As a result, it looks like the planner consumes about 250 bytes for each integer element.
>>
>> It is maybe not a problem most of the time. However, in the case of partitions, memory consumption multiplies by each partition. Such a corner case looks weird, but the fix is simple. So, why not?
>>
>> The diff in the attachment is proof of concept showing how to reduce wasting of memory. Having benchmarked a bit, I didn't find any overhead.
>
> + Const *c = makeConst(nominal_element_type,
> + -1,
> + nominal_element_collation,
> + elmlen,
> + elem_values[i],
> + elem_nulls[i],
> + elmbyval);
> +
> + args = list_make2(leftop, c);
> if (is_join_clause)
> s2 = DatumGetFloat8(FunctionCall5Coll(&oprselproc,
> clause->inputcollid,
> @@ -1984,7 +1985,8 @@ scalararraysel(PlannerInfo *root,
> ObjectIdGetDatum(operator),
> PointerGetDatum(args),
> Int32GetDatum(varRelid)));
> -
> + list_free(args);
> + pfree(c);
>
> Maybe you can just use list_free_deep, instead of storing the constant
> in a separate variable.
As I see, the first element in the array is leftop, which is used on other iterations. So, we can't use list_free_deep here.

--
Regards,
Andrei Lepikhov