Skip to content

CONCEPT Cited by 1 source

Query-structure caching

Query-structure caching caches an executable query's stable intent and syntax while leaving its variable values and result data live. For example, SELECT SUM(revenue) FROM sales WHERE quarter = {quarter} is reusable across quarters; each execution binds a current quarter and reads current database state. It is therefore a better cache object than a rendered answer when answers change frequently but query shapes repeat. (Source: sources/2026-08-13-aws-reducing-text2sql-latency-with-parameterized-query-templates)

Why it is distinct from response caching

Cache object Reuse unit Freshness behavior Main risk
Response / question-answer cache Literal prior answer Stale when source data changes Incorrect current result
Complete SQL cache One query with fixed literals Reads fresh data, but has narrow reuse Misses parameter variations
Query-structure cache SQL structure plus typed slots Reads fresh data after current binding Incorrect slot mapping or semantic match

Required invariants

  1. Slots are typed contracts, not text-replacement locations. A quarter must be an allowed quarter, a date must parse as a date, and a threshold must be numeric.
  2. Bind values as prepared-statement parameters. Validated values remain data and cannot change SQL syntax.
  3. Keep authorization and policy context in the cache key or retrieval filter. A reusable structure is not permission to reuse an answer across tenants or roles.
  4. Validate result sufficiency. A syntactically valid query may still omit a requested breakdown or return incomplete information.

Seen in

Last updated · 622 distilled / 1,953 read