On Mon, Sep 4, 2023 at 11:58 AM Lepikhov Andrei
<[email protected]> 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.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
