A New Google Patent Lets a Database Switch Tactics While It Searches
Databases usually pick a search plan from a guess and then stick with it, even when the guess turns out wrong. Google's patent application describes one that watches how the search is going and changes course in the middle.
What Google's mid-search strategy switch does
Today, when a database looks for something like 'items similar to this photo, but under $100,' it picks its game plan before it examines a single record. That plan rests on an educated guess about how many items will match, and the guess can be way off.
When it is, the search can drag, or it can leave out some of the best answers. Google's patent application describes a database that starts the search, watches how things actually go, and switches tactics partway through if the early results don't match what it expected.
It works like a driver who hits a traffic jam on the highway and reroutes instead of sitting in it. For you, the payoff would be faster, more complete results in apps that search by meaning, such as finding products similar to a phrase or a picture while also applying filters like category, price or region.
… generating, by the computing system and during execution of the first portion of the query, runtime statistics of the first portion of the query; determining, by the computing system and based on the runtime statistics, whether to execute a second portion of the query by at least applying a second evaluation strategy of the set of evaluation strategies …
Translation: The system tracks how the search is going and decides midstream whether to switch tactics.
How the database checks its guess against reality
Each record in the database holds a vector (a list of numbers that captures the meaning of text, an image or audio) plus ordinary fields like price, category or region. A search combines a query vector (the meaning you are looking for) with filter conditions (the rules, like price under 100).
There are several ways to run that search, and the filing names four:
- Pre-filtering: apply the filters first, then rank the survivors by similarity.
- Post-filtering: find the closest matches first, then apply the filters.
- Inline filtering: check the filters while scanning the index, using a bitmap (a checklist marking which records pass).
- Hybrid: some filters inline, the rest afterward.
The database starts with one strategy and collects runtime statistics (live measurements) as it goes. It compares the number of matches it estimated beforehand with the number it actually finds. If the gap crosses a switching threshold, it changes strategy. In one example, it expects 1,000 matches and gets 5,000.
Overestimating matches (100,000 expected, 100 found) moves an inline search to pre-filtering. Underestimating moves it to post-filtering. It can also switch when the search meaning and the filter pull in opposite directions, like a search for 'sports' filtered to formalwear. A switch can mean throwing away the first attempt's results and restarting from scratch.
… executing a first portion of the query on a relational database by at least applying a first evaluation strategy. The first evaluation strategy is from a set of evaluation strategies. The method additionally includes generating, during execution of the first portion of the query, runtime statistics of the first portion of the query.
Translation: The database begins searching using an initial plan while constantly measuring its own performance.
Why Google's fix matters for search-powered apps
Searching by meaning and then narrowing by price, date or region is how a growing number of apps find things, and it is where a wrong guess hurts most. The filing says a bad plan can cost speed or recall (how many of the truly relevant results get found). Switching to an exact strategy can return every matching record, which the filing describes as a recall of 1.
The filing lists the benefits as saving energy, using less hardware and finishing searches sooner. It also describes a lighter way to track matches (a flat hash, a compact lookup table) that in some cases cut delay by a factor of two or more compared with the standard checklist. The described setup is a PostgreSQL-style database in a cloud environment. The filing names no specific Google product.
Google's 855th filing in our Google coverage since May continues its AI search work, following patents on a self-contained fact lookup and a big-question research tool.
You would never see this feature, and that is the point. What you would notice is a failure that doesn't happen: a shopping search that loads instead of stalling, or a results page that includes the item you obviously meant.
One example in the filing shows why it helps. Someone searches 'sports' with a filter for formalwear. The best matches for the phrase fail the filter, and the items that pass the filter look nothing like the phrase. A database working from a bad guess can burn time hunting through the wrong pile, and spotting that early and starting over is a sensible fix.
Expect this to stay invisible plumbing, valuable mostly to whoever runs the database. Faster, fuller results are a benefit any user of a search-driven app would feel, though nothing in the filing ties it to a particular Google product.
Get our take in your Top Stories
Liked this breakdown? Add Patentlyze as a preferred source on Google, and our plain-English take shows up more often in your Top Stories the next time Google patent news breaks.
There are more where this came from
We read every patent application Big Tech publishes and send you the ones worth knowing. Plain English, free, every week.
The drawings
2 drawing sheets from US 2026/0310670 A1 · click any drawing to enlarge
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →
Be the first to weigh in