# Bound every log-query branch before trusting a short displayed time range

> Why can a Log Analytics query for recent data still scan an entire table's history?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-372-bound-every-log-query-branch-before-trusting-a-short-displayed-time-range/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:25:44+00:00
- Modified: 2026-09-10T02:01:56+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Why can a Log Analytics query for recent data still scan an entire table's history?

## Potentially affected

Azure Monitor Logs queries containing joins, unions or other subqueries.

## DSE recommendation

Make each branch's intended TimeGenerated boundary explicit and verify that any optimization preserves the investigative question.

## Article

## Source facts

Azure Monitor Logs partitions data by TimeGenerated. Microsoft’s optimization guidance requires a time filter in each subquery: a recent-data filter on one join input does not automatically bound another input. Its example shows an unbounded latest-record aggregation scanning the other table’s history. Filtering after a union can likewise leave earlier branch scans unbounded. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/query-optimization).

The measured scan span can exceed the requested interval because entire storage partitions are read. In multi-region or multi-workspace queries, that indicator can also cover only part of the execution. It is not an exact global measure of the requested window. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/query-optimization).

## Applicability

Review Azure Monitor Logs queries containing joins, unions or other subqueries, especially when the same query moves between interfaces. Identify whether each branch should retrieve recent activity or an older last-known state before changing its scope.

## DSE recommendation

DSE recommends annotating the intended time window beside each table reference during query review. Where the branches should share a boundary, use one clearly defined cutoff consistently. Do not discard an intentionally older state record merely to make a performance number smaller. Ask the investigation owner to approve any change in the question being answered.

## Verification

Compare results before and after the proposed filters over a known dataset. Inspect the query’s processed time span and execution details while allowing for partition and cross-workspace measurement limitations. Check records near the boundary and known older state records. Retain both the semantic comparison and performance observations before promoting the revised query.

## Official references

[Microsoft Learn: Optimize log queries](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/query-optimization).

## Primary reference

- Name: Optimize log queries in Azure Monitor - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/logs/query-optimization
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Bound every log-query branch before trusting a short displayed time range,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-372-bound-every-log-query-branch-before-trusting-a-short-displayed-time-range/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.