[aliszka]

An in-place Or now keeps the union in the target container's existing slot whenever the slot holds it, instead of appending a new container to the bitmap's buffer. Array ∪ array and array ∪ bitmap follow one rule set; bitmap ∪ anything is unchanged.

Motivation

Merging many bitmaps into one with in-place Ors grew its buffer needlessly. An array container's Or picked its result type from the sum of both cardinalities, and array ∪ bitmap always returned a new bitmap, so a union that fit the existing slot still left it as dead space and appended an 8 KB bitmap.

Approach

The result type follows the real union cardinality: an array stays in its slot if it fits, a bitmap-sized slot always takes the union as a bitmap (later Ors set bits in place, and compaction picks the type by cardinality anyway), and only a union that fits neither is returned. When the slot has room for both arrays, the merge runs backwards straight into it with no buffer.

Knowing the real cardinality first would cost a merge that is often thrown away, so array ∪ array bounds the union from its range edges, with at most one binary search per end, and builds the bitmap directly when the bound rules out an array. Array ∪ bitmap builds the bitmap first and extracts it into the slot only when it fits; a counted merge into the slot was slower and was dropped.

Two helpers make the bitmap-first route cheap: listing a bitmap's values reads 64 bits at a time, and ORing array values into a bitmap builds one mask per uint64 word, keeping the per-value loop for sparse arrays (BenchmarkOrValues sweeps the threshold).

Key areas for review

• container_opt.go orArrayAlt, unionMayFitArray, canFitArray, bitmapUnionResult: the type rule; slots from older data, including arrays past 2044 values, are decided from their headers.
• bitmap_opt.go masked Or loops in CopresenceByMask and AndMasked: an inline Or can now return the bitmap operand itself, so they read it in place and copy it only before writing.
• container.go bitsIntoArray64 and orValuesByMask: unsafe uint64 views over container words.

Risks

• Two shapes are slower and accepted: interleaved arrays whose union just passes array size, and a small array in an oversized slot ∪ a bitmap. BenchmarkOrArrayShapes and BenchmarkOrArrayBitmap reproduce them.
• No serialized-format change: a bitmap-sized slot holding few values is still a bitmap container, decoded by its header.
• Not covered: no in-tree benchmark compares array ∪ bitmap's bitmap-first route with a counted merge.

Testing

TestOrArrayAltResult and TestOrArrayBitmapAltResult table-test every route against slot type and size, legacy slots included; TestOrMergesArraysInPlace covers the public path; TestAndMasked and TestCopresenceByMask pin the operand aliasing.

🤖 Generated with Claude Code

[orca-security-eu]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Infrastructure as Code	0   0   0   0	View in Orca
Passed	SAST	0   0   0   0	View in Orca
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca