Patzifist commented on code in PR #864:
URL: https://github.com/apache/arrow-go/pull/864#discussion_r3559410799
##########
parquet/metadata/bloom_filter.go:
##########
@@ -549,6 +551,46 @@ func (r *RowGroupBloomFilterReader) GetColumnBloomFilter(i
int) (BloomFilter, er
return bf, nil
}
+// VisitColumnBloomFilter invokes fn for the BloomFilter of the column at
index i.
+//
+// Lifetime contract: The BloomFilter passed to fn (and its backing bitset)
+// is recycled immediately after fn returns. Callers must not retain, store,
+// or use the BloomFilter or its data outside the scope of the fn function.
+func (r *RowGroupBloomFilterReader) VisitColumnBloomFilter(i int, fn
func(BloomFilter) error) error {
Review Comment:
1.Yes, that is exactly the intent. I discovered that when processing massive
datasets (e.g., 10+ Terabyte Parquet files), relying solely on GC recycling for
Bloom filters causes massive memory spikes and leads to OOM issues because the
garbage collector cannot keep up with the allocation rate.I plan to adopt
VisitColumnBloomFilter immediately in iceberg-go to explicitly reuse and
recycle the buffers. This prompt-return mechanism is essential for keeping the
memory footprint stable under heavy production workloads.
2.Agreed, that's a very good point about pool pollution. I will address this
by introducing a dedicated per-reader bloom pool in a follow-up PR right after
this one gets merged.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
