perf(weave): skip zero-limit page queries

[gtarpenning]

Summary

• return immediately after the count query when a paginated request has limit=0
• avoid building or issuing a list query that cannot return rows
• preserve the existing count-plus-list behavior for positive limits

Why

Paginated agent queries return both total_count and a page of rows. The shared
handler currently issues both ClickHouse statements even when callers request
limit=0 and only consume total_count.

The zero-limit list statement reads no rows or bytes, but it still pays to parse,
analyze, and plan the normal spans-list query, including sorting, trace
attribution, a self-join, aggregation, and set construction.

Production evidence

Read-only production measurements used active projects at the p50, p95, and
maximum span-volume points from the preceding 24 hours. Each result is the
median of three executions against a fixed snapshot:

Sample	Spans in 24h	Old stats	Count query	Zero-limit list	After this change
p50	144	8.5 ms	4.6 ms	74.9 ms	4.6 ms
p95	16,368	12.8 ms	6.7 ms	78.5 ms	6.7 ms
Maximum	1.61M	197.1 ms	7.5 ms	97.0 ms	7.5 ms

The zero-limit statement reported zero rows and zero bytes read in every run.
Skipping it removes one ClickHouse statement per count-only request. At the
observed volume of roughly 560k requests per day, that is roughly 560k fewer
statements per day.

The count statement also reduced bytes read:

Sample	Old stats bytes	Count bytes	Reduction
p50	123 KB	123 KB	<1%
p95	10.2 MB	1.83 MB	82.1%
Maximum	3.77 GB	2.34 MB	99.94%

EXPLAIN indexes=1

For the p95 project, both the old aggregation and count query narrowed the
primary key to 99 of 295,262 granules. The count query then used:

AggregatingProjection
  ReadFromPreparedSource (_exact_count_projection)

The zero-limit list plan still contained:

Sorting
  Join
    Limit (preliminary LIMIT)
      Sorting
        ReadFromMergeTree (spans)
    CreatingSets
      Aggregating
        ReadFromMergeTree (spans)

ClickHouse ultimately reduced the attribution branch to Ranges: 0, explaining
the zero data read, but the full list plan still had to be constructed.

Behavior

• limit=0: execute the count query once, return its total_count, and return
  an empty row list
• limit>0: continue executing the existing count and list query pair
• no API schema or response-shape changes
• no breaking changes

Validation

• uv run --group test python -m pytest tests/trace_server/test_genai_agent_query_handler.py -v — 3 passed
• uvx ruff check weave/trace_server/agents/clickhouse.py tests/trace_server/test_genai_agent_query_handler.py
• uvx ruff format --check weave/trace_server/agents/clickhouse.py tests/trace_server/test_genai_agent_query_handler.py
• commit hooks: ty, Pyright, mypy, import-linter, Fixit, Ruff, and repository hygiene checks passed
• git diff --check

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!