---
id: "lib-2026-11-06-from-query-plan-diagnostics-to-a-text-to-sql"
type: "library"
title: "From query plan diagnostics to a Text-to-SQL model (От диагностики плана запроса до Text-to-SQL модели. Дмитрий Безруков.)"
lang: "RU"
org: "Arenadata"
source_type: "Talk"
date: "2026-11-06"
week: "2026-W45"
url: "https://nosov.ai/library/lib-2026-11-06-from-query-plan-diagnostics-to-a-text-to-sql/"
original_url: "https://www.youtube.com/watch?v=b2Fg4VT4KM0"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "Arenadata's technical lead presents his own product with a step-by-step fine-tuning history and accuracy numbers, but the benchmark and golden set are built in-house and accuracy counts result matches only."
summary_basis: "transcript"
original_minutes: "45"
tags: ["ai technology", "business transformation"]
---

# From query plan diagnostics to a Text-to-SQL model (От диагностики плана запроса до Text-to-SQL модели. Дмитрий Безруков.)

Tier B (Useful, limited): Arenadata's technical lead presents his own product with a step-by-step fine-tuning history and accuracy numbers, but the benchmark and golden set are built in-house and accuracy counts result matches only.

Summary based on the full transcript.

## In short

A talk (YouTube, 6 November 2026) by Dmitry Bezrukov, technical lead for ADQM and ADQM Control at Arenadata, on diagnostics built into ADQM, the company's ClickHouse distribution, for customer environments the vendor cannot see. ADQM Notebook merges six explain and log sources into one plan with fix hints; ADQM Control detects anomalous hosts, splits query time into own work and waiting, and attributes load to users. A Text-to-SQL model fine-tuned for the ClickHouse dialect runs inside the customer perimeter and reaches 64% accuracy against 27.5% for an open-source SQL model.

## Key numbers

- 27.5% to 64%: Text-to-SQL accuracy on about 1,000 business questions, open-source SQL model versus the fine-tuned model with value hints and one rewrite
- 215 to 64: generated queries rejected by ClickHouse, baseline versus after the third iteration (about 3.5x fewer)
- ~28,000: examples in the first LoRA fine-tune (about 7,000 ClickHouse-specific, 76 schemas), worth +14.7 points
- 3-6 s / 10-45 s: answer time on an Nvidia L4 24 GB versus on CPU
- 26%: share of query time lost to other load in a load-test example (22 s own time, 8 s waiting, 3,000 runs)

## What it reports

- Problem: in closed environments the vendor sees "the query is slow", a screenshot or a log fragment; the same questions repeat across clients and were analysed by hand.
- Query plans: three EXPLAINs run in parallel before a query, query_log and processor_profile_log after it; one example shows 0 of 92 granules pruned because the filter missed the sort key, with suggested fixes.
- ADQM Control: in one August window queries ran 40% longer and p95 was almost 11 s higher; hosts are compared with their own history, with neighbours, and on broken metric correlations.
- Hugging Face lists 5,000+ SQL models but only 3 for ClickHouse, none with published quality, so Arenadata fine-tuned its own.
- Five iterations: LoRA on about 28,000 examples (42%); larger adapter (44%); 41,000 function-coverage examples (about 46%); about 1,000 relative-date pairs (45.6% to about 54%); value hints from the database plus one rewrite on error (about 64%).
- A test on 175 analyst-style questions over four unseen open datasets exposed failures on "yesterday" or "last week".
- Generated SQL is read-only; a filter rejects non-SQL requests; up to 10 tables go into the prompt after ranking. Ships in ADQM 26.8 Enterprise.
- Q&A: the base model is about 27B parameters (the speaker first said 147M, then corrected); no sizing for 30-100 analysts; no protection against valid but very expensive queries; a person decides whether to run.

## How they got it

Accuracy is the share of generated queries whose executed result matches the expected result, on a golden dataset Arenadata built itself; all training data was also built in-house. Query efficiency is not measured.

## Limits

- Vendor talk about its own product, with webinar plugs.
- In-house benchmark; result-match accuracy ignores cost and efficiency of the SQL.
- Read from auto-captions: the base model's name is garbled and the parameter count was corrected live.

## Why it matters for companies

The fine-tuning log is the useful part: dialect-specific examples gave the largest jump, targeted examples fixed relative dates, and the second-largest gain came from outside the model (value hints from the data plus one self-correction). For firms that cannot send data to external APIs, a mid-sized model on one GPU inside the perimeter is shown to be workable. At 64% accuracy, generated SQL still needs a person to check it, and nobody yet guards against valid but costly queries.

## Key passages in translation

> Новый сервис Text to SQL даёт 64% верных ответов вместо 27,5 у open source модели.

The new Text-to-SQL service gives 64% correct answers instead of 27.5% for the open-source model.

> А при ошибке модель один раз переписывает запрос, это и есть у нас фактически цикл исправления.

And on an error the model rewrites the query once; that is in effect our correction loop.

> Если запрос выполняется в ClickHouse и выдаёт тот набор данных, который я от него ожидаю, значит, я считаю, что модель написала правильный запрос.

If the query runs in ClickHouse and returns the data set I expect from it, I consider that the model wrote a correct query.

Original: https://www.youtube.com/watch?v=b2Fg4VT4KM0