Skip to content

INSERT plans could generate large cache entries #3209

@hatyo

Description

@hatyo

If an INSERT plan is attempting to add a relatively large number of rows to a table, it might end up generating a relatively large cache entry, having too many of these plans stored in the cache could lead to OOM without an aggressive eviction strategy.

For example, a query like:

insert into t((a, b, c, d, e, f, d), (I, j, k, l, m), n, o, p)
values 
(('x1A', 'x2', 'x3', 'x4, 'x5', 'x6', 'x7'), ('x8', 'x9', 'x10', 'x11', 'x12'), 'x13', 42, [43, 44, 45, 46, 47, 48, 49, 49, 49, 49, 49]),
(('x1B', 'x2', 'x3', 'x4, 'x5', 'x6', 'x7'), ('x8', 'x9', 'x10', 'x11', 'x12'), 'x13', 42, [43, 44, 45, 46, 47, 48, 49, 49, 49, 49, 49]),
(('x1C', 'x2', 'x3', 'x4, 'x5', 'x6', 'x7'), ('x8', 'x9', 'x10', 'x11', 'x12'), 'x13', 42, [43, 44, 45, 46, 47, 48, 49, 49, 49, 49, 49]),
...
(('x1Z', 'x2', 'x3', 'x4, 'x5', 'x6', 'x7'), ('x8', 'x9', 'x10', 'x11', 'x12'), 'x13', 42, [43, 44, 45, 46, 47, 48, 49, 49, 49, 49, 49])

ends up generating hundreds of RCVs containing hundreds of Type instances, moreover, the generated QueryPlanConstraint will end up with a boolean expression (QueryPredicate) containing thousands of terms. Profiling shows that the overall retain size is several megabytes.

Metadata

Metadata

Assignees

No one assigned

    Labels

    performancePerformance issuesrelationalissues related to relational FDB

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions