Could one AI query slow down your order screen?

#Heavy queries are stopped before they run, and the AI learns why

When the AI starts scanning a table of hundreds of millions of rows on your production database with no filter, the order screen and the settlement batch that share that database slow down from that moment on.

With OwlDB, a query like this is filtered out before it runs, and a query that overuses resources while running is stopped together with its database session. The reason goes back to the AI, which reads it and rewrites the SQL.

#OwlAI alone caps time and rows

Even without OwlDB, every query OwlAI runs carries a time budget. When the budget runs out, OwlAI cancels the query, and it also sets a time limit on the database side in case that cancellation fails. When someone stops an answer, the cancellation reaches queries already sent to the database (“Put AI on the production database, and security asks three questions”). The number of rows fetched at once is capped too.

All of these safeguards act after the query has started. A direct connection sees the database through a single connection, so it has little to go on when judging in advance how many sessions are running on that database right now or how heavy this query will be.

#With OwlDB, three stages stand in the way

OwlDB manages the database, so it already knows the database's current state. That lets it deal with a heavy query in three stages.

Before execution, OwlDB decides. When the AI checks an execution plan, OwlDB also decides whether that plan exceeds the threshold set in OwlDB, and if it does, it points to the part that makes it heavy.

During execution, CPU, I/O, memory, and time are capped. Some queries look light in the execution plan and turn out heavy once they actually run.

Throughout, OwlDB checks sessions every second and forcibly ends any session that exceeds its budget. On a direct connection, the most OwlAI can do is send a cancel request and keep a time limit on the database side in case that request doesn't take. After that, the engine decides when to stop the work it has already started. OwlDB ends the database session itself.

#The AI fixes the queries that get blocked

Blocking a query on its own leaves the person who asked without an answer. A rejection from OwlDB states whether the query exceeded the cost threshold or the row limit, along with the part that caused it. In the next step, the AI rewrites the SQL, for example by adding a date range or selecting only the columns it needs. If the rewritten SQL passes, all the person sees is an answer that arrives a little later.

When the cause has nothing to do with the SQL, such as a read replica being briefly unavailable or the database being busy, OwlAI simply retries a little later.

#What to check before adoption

• The execution time and resource caps you will allow for AI queries on the production database
• The records your database administrator receives when a heavy query is blocked
• Whether a standby node can take analysis and queries instead of the primary node (“The standby database: can it take AI queries off production?”)