Indexed fields with tstats versus search-time extraction for high-volume Splunk searches

In Splunk Enterprise, a high-volume search over large event volumes can be classified as scan-bound using the Search Job Inspector, which reports component-level execution costs and statistics such as scanCount. The unresolved decision is whether to extract the relevant fields at index time so tstats can query tsidx files directly, or to retain search-time extraction for schema flexibility.

Indexed fields accelerate tstats but enlarge the index and lock the schema; correcting a bad extraction later requires re-ingesting affected data. Search-time extraction remains correctable but forces every search to parse raw events. Data model acceleration sits between the two by building tsidx summaries in the background, adding indexer CPU and disk while limiting coverage to data that fits the model.

A single Job Inspector run reflects one execution under one load level, so caching, concurrency, and distributed deployments can shift results. The trade-off depends on how frequently the search runs versus how much data it scans, which varies by workload and is not resolved by the inspector alone.

What factors should determine the choice between indexed fields with tstats, search-time extraction, or data model acceleration for a scan-bound search? How can a bounded side-by-side comparison clarify whether the speed gain justifies the storage overhead and schema lock-in before any ingest-time change?