Re: Optimize planner memory consumption for huge arrays
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Lepikhov Andrei <a.lepikhov@postgrespro.ru>
Cc: pgsql-hackers@lists.postgresql.org, Евгений Бредня <e.brednya@postgrespro.ru>
Date: 2023-09-04T08:37:03Z
Lists: pgsql-hackers
On Mon, Sep 4, 2023 at 11:58 AM Lepikhov Andrei
<a.lepikhov@postgrespro.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.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com