Estimate query response time when searching across a large log index.
Log search time is a function of how much data must actually be scanned relative to the search cluster's throughput: search_time = index_size ÷ search_throughput, but effective scan volume shrinks dramatically once filters (time range, indexed fields, term filters) narrow the search space: search_time = (index_size × optimization_factor) ÷ search_throughput. A tight time-range filter combined with selective field queries is usually the single biggest lever for search latency.
search_time_sec = data_scanned_GB / scan_throughput_GBps
Narrowing the time range is usually the most effective optimization, since most log search backends partition data by time (daily/hourly indices) and can skip entire index segments outside the requested range without scanning them at all.
Querying on low-cardinality, indexed fields (e.g. exact service name or log level) lets the search engine use inverted indices to jump directly to matching documents, versus full-text search across unindexed or highly variable fields which requires scanning much more data.
Both matter — larger indices take proportionally longer to scan per this model, but poor shard sizing (too few large shards, or too many tiny shards) also hurts parallelism and can dominate actual query latency beyond what this simplified model captures.
Cluster resource contention (CPU, JVM heap pressure, concurrent queries), cold caches on infrequently-queried indices, and complex aggregations beyond a simple filtered scan can all add latency this linear throughput model doesn't capture.