[Feature] Optimize FieldCollectAgg and FieldMergeMapAgg lookup performance #363

Search before asking

• I searched in the issues and found nothing similar.

Motivation

Problem

FieldCollectAgg and FieldMergeMapAgg currently use linear scans with
FieldAggregateUtils::Equals for distinct-value and key lookup.

For large arrays/maps, repeatedly scanning previously collected values causes
quadratic behavior.

For example:

• FieldCollectAgg scans previously collected elements to detect duplicates.
• FieldMergeMapAgg scans existing keys through FindKey before
  overwriting or inserting an entry.

The implementation already contains a TODO noting that these lookups should use
type-aware hashing for hashable types, similar to the Java implementation.

Solution

Proposed improvement

Add a hash-backed lookup path for types with well-defined semantic hashing,
while preserving the existing aggregation behavior.

The optimized path should:

• process both accumulator and input values;
• preserve first-seen order for FieldCollectAgg;
• preserve key order and input-overwrite semantics for FieldMergeMapAgg;
• hash STRING/BINARY by content;
• preserve FLOAT/DOUBLE semantics:
  • all NaNs compare equal;
  • -0.0 and +0.0 remain distinct;
• support TIMESTAMP consistently with its equality semantics;
• retain the existing linear fallback for DECIMAL and constructed types;
• retain linear lookup for small cardinalities where hash-table construction
  overhead is higher.

FieldNestedUpdateAgg can be considered separately as follow-up work.

Performance

Focused benchmarks using the production aggregators show that the quadratic
lookup becomes significant once cardinality grows.

At 192 elements/entries:

At 8192 elements/entries:

Small-cardinality performance remains approximately unchanged by retaining the
existing linear path below the hash threshold.

Related PR

#349

Anything else?

No response

Are you willing to submit a PR?

• I'm willing to submit a PR!