Reducing Memory Usage in Transaction with fields Option

Quick Answer

The memory problem in a large, high-cardinality transaction search comes from how much data transaction has to hold onto for every event while it waits for a transaction's boundary to close: every field on every event sits in memory until that event's group is finalized. Since transaction itself still needs to run, and the grouping logic, maxspan and the cardinality of the correlating fields, isn't changing, the effective lever left is reducing how much data each event carries into that memory-intensive stage in the first place. The fields command applied before transaction strips each event down to only the fields actually needed, the correlation field(s) and _time, so transaction is buffering a much smaller payload per event even though it's still holding just as many events in memory during the same window. This directly shrinks memory usage without touching the transaction logic itself, unlike alternatives that either change the underlying approach, like switching to stats, which alters event-boundary behavior, or don't actually reduce memory, like increasing maxpause, which can enlarge the window of open transactions, or keeping evicted events, which keeps more data resident rather than less. The general takeaway is that when a scenario asks you to reduce a transaction's memory footprint without changing its underlying logic, the fields command trimming unnecessary fields before the memory-intensive stage is the pattern to reach for.