refactor query_execution (#44457)

Co-authored-by: Copilot Autofix powered by AI <[email protected]>

4 files changed, 119 insertions, 80 deletions

diff --git a/ydb/docs/ru/core/concepts/glossary.md b/ydb/docs/ru/core/concepts/glossary.md
index 8736bf4cf85..14cb293c10b 100644
--- a/ydb/docs/ru/core/concepts/glossary.md
+++ b/ydb/docs/ru/core/concepts/glossary.md
@@ -114,7 +114,7 @@
 
 ### Сессии
 
-Логические соединения с базой данных, которые хранят контекст, необходимый для выполнения запросов и управления транзакциями. Более подробно сессии описаны в разделе [{#T}](query_execution/index.md#sessions).
+Логические соединения с базой данных, которые хранят контекст, необходимый для выполнения запросов и управления транзакциями. Более подробно сессии описаны в разделе [{#T}](query_execution/execution_process.md#sessions).
 
 ### Клиентский таймаут {#client-timeout}
 
diff --git a/ydb/docs/ru/core/concepts/query_execution/execution_process.md b/ydb/docs/ru/core/concepts/query_execution/execution_process.md
new file mode 100644
index 00000000000..7aaeadefa09
--- /dev/null
+++ b/ydb/docs/ru/core/concepts/query_execution/execution_process.md
@@ -0,0 +1,97 @@
+# Процесс выполнения запросов
+
+Эта статья описывает процесс выполнения запросов в {{ ydb-short-name }}. Она предназначена для ознакомления пользователей с возможностями и ограничениями движка выполнения запросов {{ ydb-short-name }}, включая ключевые особенности, такие как поддерживаемый язык запросов и общий порядок их выполнения. Также здесь вводится базовая терминология и концепции, которые используются в других разделах документации.
+
+{{ ydb-short-name }} предоставляет единый интерфейс для выполнения запросов, способный эффективно обрабатывать широкий спектр нагрузок — от высоконагруженных [транзакционных OLTP-запросов](https://ru.wikipedia.org/wiki/OLTP) до сложных [аналитических OLAP-запросов](https://ru.wikipedia.org/wiki/OLAP). Такой подход позволяет приложениям выполнять транзакционные и аналитические запросы прозрачно, без необходимости использовать разные API для разных типов нагрузки.
+
+Для выполнения запросов используется распределённый движок, спроектированный с учётом масштабируемости и эффективности в больших распределённых средах. При запуске запроса {{ ydb-short-name }} автоматически распределяет работу между несколькими узлами, максимально учитывая локальность данных — обрабатывает данные там, где они хранятся. Это снижает избыточные сетевые пересылки. Кроме того, применяется вычислительный pushdown (вынос фильтрации и вычислений ближе к слою хранения), что дополнительно ускоряет обработку. Благодаря этим техникам {{ ydb-short-name }} эффективно справляется со сложными запросами и большими нагрузками на уровне кластера.
+
+## Общий порядок работы
+
+Далее описан пошаговый процесс обработки SQL-запросов в {{ ydb-short-name }}. Знание этого процесса помогает лучше понять архитектуру и внутреннее устройство {{ ydb-short-name }}.
+
+![Процесс выполнения запроса](_assets/query_workflow.png "Процесс выполнения запроса")
+
+1. **Подключение к базе данных**
+   Приложение использует один из [официальных SDK {{ ydb-short-name }}](../../reference/ydb-sdk/index.md) для подключения к базе данных. SDK автоматически управляет пулом сессий — логических подключений, необходимых для выполнения запросов. Каждая сессия физически связана с одним из узлов кластера. Когда требуется выполнить запрос, SDK предоставляет готовую сессию из пула, избавляя разработчика от необходимости ручного управления соединениями.
+
+2. **Начало транзакции и отправка запроса**
+   Используя активную сессию, приложение может начать транзакцию и сформировать запрос на языке [YQL](../../yql/reference/index.md) согласно своей бизнес-логике, после чего отправить его в кластер {{ ydb-short-name }}.
+
+3. **Парсинг и поиск в кеше планов**
+   На серверной стороне узел {{ ydb-short-name }}, получивший запрос, сначала проверяет его корректность (парсинг и анализ). Затем система проверяет наличие готового физического плана выполнения в кеше запросов. Если план найден, он используется повторно.
+
+4. **Оптимизация и подготовка плана**
+   Если подходящего плана нет, [оптимизатор запросов](optimizer.md) формирует новый физический план, определяющий наиболее эффективный способ выполнения запроса в распределённой системе. Подробнее о принципах оптимизации запросов и видах планов см. в статье [{#T}](optimizer.md).
+
+5. **Распределённое выполнение запроса**
+   Согласно подготовленному физическому плану {{ ydb-short-name }} начинает распределённое выполнение запроса: обработка делится между несколькими узлами, каждый из которых отвечает за свою часть расчетов или обращения к данным согласно полученному плану. Такой параллелизм обеспечивает высокую скорость и масштабируемость выполнения даже для объёмных выборок.
+
+6. **Потоковая передача результатов клиенту**
+   Если запрос возвращает результат (`SELECT` и т. п.), он поступает в приложение в виде одного или нескольких результирующих наборов, которые представляют собой строго типизированные таблицы. Данные передаются потоково (частями), это позволяет обрабатывать результаты сразу по мере поступления и эффективно работать с большими выборками, не загружая всю выборку в память.
+
+7. **Продолжение или завершение транзакции**
+   После получения результатов приложение может либо продолжить транзакцию, отправив дополнительные запросы в её контексте, либо завершить её фиксацией изменений (commit).
+
+Более подробное описание перечисленных этапов и связанных с ними понятий приведено в отдельных разделах ниже.
+
+## Сессии {#sessions}
+
+Сессия в {{ ydb-short-name }} — это логическое "соединение" с базой данных, которое хранит контекст, необходимый для выполнения запросов и управления транзакциями. Внутри сессии поддерживается состояние транзакций и другая рабочая информация, что позволяет выполнять связанные друг с другом запросы как часть одной транзакции. Большинство операций с запросами выполняется в контексте активной сессии.
+
+Сессии являются долгоживущими объектами. Одна из их важных задач — эффективное распределение нагрузки: за счёт распределения сессий и связанных с ними запросов по разным узлам кластера {{ ydb-short-name }} достигает высокой доступности и масштабируемости.
+
+На практике создавать, переиспользовать и удалять сессии вручную не требуется. Все официальные SDK для {{ ydb-short-name }} предоставляют встроенный пул сессий: SDK сам управляет жизненным циклом сессий, создаёт их по мере необходимости, повторно использует и возвращает обратно в пул — всё это прозрачно для пользователя и не требует дополнительной логики в приложении.
+
+## Транзакции
+
+Каждый запрос в YDB выполняется в контексте транзакции, что обеспечивает согласованность и надёжное хранение данных. Транзакциями можно управлять явно (через отдельные вызовы в SDK) или указывать соответствующие флаги во время выполнения запроса.
+
+YDB также поддерживает [интерактивные транзакции](../glossary.md#interactive-transaction), которые дают возможность выполнять несколько запросов в рамках одной транзакции, позволяя при этом вашему приложению выполнять пользовательскую логику между этими запросами. Это позволяет строить сложные рабочие процессы, в которых требуется рассматривать несколько связанных операций как единую атомарную единицу.
+
+Для получения подробной информации о транзакциях и доступных режимах транзакций в {{ ydb-short-name }} смотрите статью [Транзакции](../transactions.md).
+
+## Повторные выполнения (Retries)
+
+В {{ ydb-short-name }} применяется механизм [оптимистичных блокировок](https://en.wikipedia.org/wiki/Optimistic_concurrency_control) для управления транзакциями. Это означает, что транзакция может быть прервана во время выполнения, если выявлен конфликт и система не может гарантировать нужный уровень изоляции — например, если две транзакции одновременно изменяют одни и те же данные. Помимо конфликтов, в распределённой среде возможны временная недоступность отдельных узлов из-за сетевых сбоев, отказов оборудования или технических работ, что также может привести к необходимости повторного выполнения транзакции.
+
+Повторное выполнение всегда следует реализовывать на уровне всей транзакции, а не отдельного запроса. В [интерактивных транзакциях](../glossary.md#interactive-transaction) последовательность выполнения и промежуточные результаты отдельных запросов могут влиять на последующие действия. Поэтому, если запрос завершился ошибкой из-за конфликта или временной ошибки, необходимо повторять всю транзакцию с самого начала, чтобы обеспечить корректность и консистентность данных.
+
+Все официальные SDK для {{ ydb-short-name }} предоставляют встроенные механизмы управления транзакциями и повторным выполнением, упрощающие написание приложений. Используя стандартные механизмы повторного выполнения транзакций из SDK, вы автоматически получаете корректную реализацию логики повторного выполнения без необходимости реализовывать её вручную. Подробнее о механизмах повторного выполнения для различных SDK см. [{#T}](../../reference/ydb-sdk/error_handling.md).
+
+## Язык запросов
+
+Запросы для {{ ydb-short-name }} пишутся на [YQL](../glossary.md#yql) — SQL-диалекте, специально адаптированном для распределённых масштабируемых баз данных. Хотя YQL не полностью совместим с ANSI SQL, он во многом сохраняет знакомый синтаксис и принципы SQL, что облегчает обучение и переход для опытных пользователей SQL. Полная справка по языку приведена в [документации по YQL](../../yql/reference/index.md).
+
+Большинство операций с данными в {{ ydb-short-name }} осуществляется именно через YQL — он является основным инструментом для работы с данными и администрирования базы. Владение YQL позволяет использовать все возможности распределённой архитектуры {{ ydb-short-name }} и реализовывать сложную бизнес-логику непосредственно в запросах.
+
+YQL поддерживает все основные конструкции SQL, в числе которых:
+
+- [Язык манипулирования данными (DML)](https://ru.wikipedia.org/wiki/Язык_манипулирования_данными): `SELECT`, `INSERT`, `REPLACE`, `UPDATE`, `DELETE`, `UPSERT`.
+- [Язык определения данных (DDL)](https://ru.wikipedia.org/wiki/Язык_определения_данных): `CREATE`, `ALTER`, `DROP` для таблиц, индексов и других объектов схемы.
+- Соединения — все стандартные виды соединений, а также специальные типы соединений (например, `LEFT SEMI`, `RIGHT SEMI`, `ANY`).
+- Агрегации — группировка (`GROUP BY`) и оконные функции.
+- [Именованные выражения](../../yql/reference/syntax/expressions.md#named-nodes) для структурирования текста запроса.
+- Большое количество встроенных функций для обработки разных типов данных и решения сложных задач прямо в запросе.
+- Прагмы (pragma) и подсказки (hints) для управления планом выполнения.
+
+## Результирующие наборы
+
+Результатом выполнения запроса в {{ ydb-short-name }} может быть один или несколько результирующих наборов (result sets). Результирующий набор похож на таблицу: он содержит строки со строгой типизацией данных в каждом столбце. Строгая типизация результатов обеспечивает предсказуемость и согласованность формата выдачи.
+
+Результирующие наборы могут содержать произвольно большой объём данных, поэтому для их эффективной передачи {{ ydb-short-name }} использует потоковую выдачу (streaming) — результат возвращается на клиент порциями (chunks). Это позволяет сразу начинать обработку данных без ожидания получения всей выборки и минимизирует использование оперативной памяти клиентским приложением.
+
+## Ограничения
+
+При работе с запросами в {{ ydb-short-name }} важно учитывать ряд ограничений:
+
+* **Отсутствие схемных транзакций**
+{{ ydb-short-name }} не поддерживает схемные транзакции, поэтому DDL-операции (создание или изменение таблиц) нельзя объединять с DML-запросами (вставка, изменение или удаление данных) в одной транзакции или одном запросе.
+
+* **Большие обновления и оптимистичные блокировки**
+{{ ydb-short-name }} применяет механизм оптимистичных блокировок. При попытке выполнить очень большие `UPDATE` или `DELETE` в рамках одной транзакции вероятность конфликтов по блокировкам сильно возрастает, делая такие операции непрактичными для реального использования. Для больших изменений рекомендуется использовать [`BATCH UPDATE`](../../yql/reference/syntax/batch-update.md)/[`BATCH DELETE`](../../yql/reference/syntax/batch-delete.md).
+
+* **Ограничения на размер транзакции**
+Объём данных, записываемых в одной транзакции, ограничен. Подробности см. в разделе [{#T}](../limits-ydb.md#query).
+
+Полный список ограничений системы приведён в [{#T}](../limits-ydb.md).
\ No newline at end of file
diff --git a/ydb/docs/ru/core/concepts/query_execution/index.md b/ydb/docs/ru/core/concepts/query_execution/index.md
index 2812a311806..d9a2bfdd31b 100644
--- a/ydb/docs/ru/core/concepts/query_execution/index.md
+++ b/ydb/docs/ru/core/concepts/query_execution/index.md
@@ -1,97 +1,37 @@
 # Выполнение запросов
 
-Эта статья описывает процесс выполнения запросов в {{ ydb-short-name }}. Она предназначена для ознакомления пользователей с возможностями и ограничениями движка выполнения запросов {{ ydb-short-name }}, включая ключевые особенности, такие как поддерживаемый язык запросов и общий порядок их выполнения. Также здесь вводится базовая терминология и концепции, которые используются в других разделах документации.
+{{ ydb-short-name }} предоставляет единый интерфейс для выполнения запросов на языке [YQL](../../yql/reference/index.md) и единый распределённый движок их выполнения. Один и тот же синтаксис и одни и те же механизмы позволяют обращаться к данным разной природы: от строк в таблицах базы данных до неограниченных потоков событий в топиках и данных во внешних системах.
 
-{{ ydb-short-name }} предоставляет единый интерфейс для выполнения запросов, способный эффективно обрабатывать широкий спектр нагрузок — от высоконагруженных [транзакционных OLTP-запросов](https://ru.wikipedia.org/wiki/OLTP) до сложных [аналитических OLAP-запросов](https://ru.wikipedia.org/wiki/OLAP). Такой подход позволяет приложениям выполнять транзакционные и аналитические запросы прозрачно, без необходимости использовать разные API для разных типов нагрузки.
+С точки зрения пользователя запросы выполняются к трём типам сущностей:
 
-Для выполнения запросов используется распределённый движок, спроектированный с учётом масштабируемости и эффективности в больших распределённых средах. При запуске запроса {{ ydb-short-name }} автоматически распределяет работу между несколькими узлами, максимально учитывая локальность данных — обрабатывает данные там, где они хранятся. Это снижает избыточные сетевые пересылки. Кроме того, применяется вычислительный pushdown (вынос фильтрации и вычислений ближе к слою хранения), что дополнительно ускоряет обработку. Благодаря этим техникам {{ ydb-short-name }} эффективно справляется со сложными запросами и большими нагрузками на уровне кластера.
+- [таблицы базы данных](#tables) — транзакционные (OLTP) и аналитические (OLAP) запросы к данным, хранящимся в {{ ydb-short-name }};
+- [внешние источники данных](#federated) — федеративные запросы к данным, расположенным за пределами {{ ydb-short-name }};
+- [топики](#streaming) — запросы к неограниченным потокам данных: потоковые запросы и бесконечные запросы к топикам.
 
-## Общий порядок работы
+Общий порядок обработки запроса, а также базовые понятия — сессии, транзакции, повторные выполнения, язык запросов и результирующие наборы — описаны в разделе [{#T}](execution_process.md).
 
-Далее описан пошаговый процесс обработки SQL-запросов в {{ ydb-short-name }}. Знание этого процесса помогает лучше понять архитектуру и внутреннее устройство {{ ydb-short-name }}.
+## Запросы к таблицам базы данных {#tables}
 
-![Процесс выполнения запроса](_assets/query_workflow.png "Процесс выполнения запроса")
+Основной сценарий — выполнение запросов к [таблицам](../datamodel/table.md), хранящимся в {{ ydb-short-name }}. Единый интерфейс способен эффективно обрабатывать широкий спектр нагрузок — от высоконагруженных [транзакционных OLTP-запросов](https://ru.wikipedia.org/wiki/OLTP) до сложных [аналитических OLAP-запросов](https://ru.wikipedia.org/wiki/OLAP).
 
-1. **Подключение к базе данных**
-   Приложение использует один из [официальных SDK {{ ydb-short-name }}](../../reference/ydb-sdk/index.md) для подключения к базе данных. SDK автоматически управляет пулом сессий — логических подключений, необходимых для выполнения запросов. Каждая сессия физически связана с одним из узлов кластера. Когда требуется выполнить запрос, SDK предоставляет готовую сессию из пула, избавляя разработчика от необходимости ручного управления соединениями.
+## Запросы к внешним источникам данных (федеративные запросы) {#federated}
 
-2. **Начало транзакции и отправка запроса**
-   Используя активную сессию, приложение может начать транзакцию и сформировать запрос на языке [YQL](../../yql/reference/index.md) согласно своей бизнес-логике, после чего отправить его в кластер {{ ydb-short-name }}.
+[Федеративные запросы](federated_query/index.md) позволяют обращаться к данным, расположенным во внешних системах, без переноса этих данных внутрь {{ ydb-full-name }}. С помощью YQL-запросов можно читать данные из внешних СУБД и объектных хранилищ (S3), а также объединять их с данными в таблицах {{ ydb-short-name }}.
 
-3. **Парсинг и поиск в кеше планов**
-   На серверной стороне узел {{ ydb-short-name }}, получивший запрос, сначала проверяет его корректность (парсинг и анализ). Затем система проверяет наличие готового физического плана выполнения в кеше запросов. Если план найден, он используется повторно.
+Подробнее см. в разделе [{#T}](federated_query/index.md).
 
-4. **Оптимизация и подготовка плана**
-   Если подходящего плана нет, [оптимизатор запросов](optimizer.md) формирует новый физический план, определяющий наиболее эффективный способ выполнения запроса в распределённой системе. Подробнее о принципах оптимизации запросов и видах планов см. в статье [{#T}](optimizer.md).
+## Запросы к топикам {#streaming}
 
-5. **Распределённое выполнение запроса**
-   Согласно подготовленному физическому плану {{ ydb-short-name }} начинает распределённое выполнение запроса: обработка делится между несколькими узлами, каждый из которых отвечает за свою часть расчетов или обращения к данным согласно полученному плану. Такой параллелизм обеспечивает высокую скорость и масштабируемость выполнения даже для объёмных выборок.
+Запросы к [топикам](../datamodel/topic.md) позволяют обрабатывать неограниченные потоки данных. Поскольку поток данных бесконечен, такой запрос не завершается после получения результата, а работает до явной отмены. Есть два варианта таких запросов.
 
-6. **Потоковая передача результатов клиенту**
-   Если запрос возвращает результат (`SELECT` и т. п.), он поступает в приложение в виде одного или нескольких результирующих наборов, которые представляют собой строго типизированные таблицы. Данные передаются потоково (частями), это позволяет обрабатывать результаты сразу по мере поступления и эффективно работать с большими выборками, не загружая всю выборку в память.
+### Потоковые запросы
 
-7. **Продолжение или завершение транзакции**
-   После получения результатов приложение может либо продолжить транзакцию, отправив дополнительные запросы в её контексте, либо завершить её фиксацией изменений (commit).
+[Потоковые запросы](../streaming-query.md) — основной способ потоковой обработки данных в production. Они оформляются как постоянные объекты схемы (`STREAMING QUERY`), читают сообщения из топиков по мере их поступления, записывают результаты в выходные топики или таблицы и автоматически восстанавливаются после сбоев из [чекпоинтов](../../dev/streaming-query/checkpoints.md).
 
-Более подробное описание перечисленных этапов и связанных с ними понятий приведено в отдельных разделах ниже.
+Подробнее см. в разделе [{#T}](../streaming-query.md) и в описании [{#T}](../../yql/reference/syntax/create-streaming-query.md).
 
-## Сессии {#sessions}
+### Запросы к топикам в табличном режиме
 
-Сессия в {{ ydb-short-name }} — это логическое "соединение" с базой данных, которое хранит контекст, необходимый для выполнения запросов и управления транзакциями. Внутри сессии поддерживается состояние транзакций и другая рабочая информация, что позволяет выполнять связанные друг с другом запросы как часть одной транзакции. Большинство операций с запросами выполняется в контексте активной сессии.
+Прочитать данные из топика можно и обычным `SELECT`, указав `STREAMING = "TRUE"` в блоке `WITH`. Без ограничения `LIMIT` такой запрос работает бесконечно, возвращая результат клиенту по мере поступления сообщений. В отличие от потоковых запросов, он не создаёт постоянного объекта схемы и не восстанавливается после сбоев, поэтому предназначен в первую очередь для отладки и проверки данных в топике.
 
-Сессии являются долгоживущими объектами. Одна из их важных задач — эффективное распределение нагрузки: за счёт распределения сессий и связанных с ними запросов по разным узлам кластера {{ ydb-short-name }} достигает высокой доступности и масштабируемости.
-
-На практике создавать, переиспользовать и удалять сессии вручную не требуется. Все официальные SDK для {{ ydb-short-name }} предоставляют встроенный пул сессий: SDK сам управляет жизненным циклом сессий, создаёт их по мере необходимости, повторно использует и возвращает обратно в пул — всё это прозрачно для пользователя и не требует дополнительной логики в приложении.
-
-## Транзакции
-
-Каждый запрос в YDB выполняется в контексте транзакции, что обеспечивает согласованность и надёжное хранение данных. Транзакциями можно управлять явно (через отдельные вызовы в SDK) или указывать соответствующие флаги во время выполнения запроса.
-
-YDB также поддерживает [интерактивные транзакции](../glossary.md#interactive-transaction), которые дают возможность выполнять несколько запросов в рамках одной транзакции, позволяя при этом вашему приложению выполнять пользовательскую логику между этими запросами. Это позволяет строить сложные рабочие процессы, в которых требуется рассматривать несколько связанных операций как единую атомарную единицу.
-
-Для получения подробной информации о транзакциях и доступных режимах транзакций в {{ ydb-short-name }} смотрите статью [Транзакции](../transactions.md).
-
-## Повторные выполнения (Retries)
-
-В {{ ydb-short-name }} применяется механизм [оптимистичных блокировок](https://en.wikipedia.org/wiki/Optimistic_concurrency_control) для управления транзакциями. Это означает, что транзакция может быть прервана во время выполнения, если выявлен конфликт и система не может гарантировать нужный уровень изоляции — например, если две транзакции одновременно изменяют одни и те же данные. Помимо конфликтов, в распределённой среде возможны временная недоступность отдельных узлов из-за сетевых сбоев, отказов оборудования или технических работ, что также может привести к необходимости повторного выполнения транзакции.
-
-Повторное выполнение всегда следует реализовывать на уровне всей транзакции, а не отдельного запроса. В [интерактивных транзакциях](../glossary.md#interactive-transaction) последовательность выполнения и промежуточные результаты отдельных запросов могут влиять на последующие действия. Поэтому, если запрос завершился ошибкой из-за конфликта или временной ошибки, необходимо повторять всю транзакцию с самого начала, чтобы обеспечить корректность и консистентность данных.
-
-Все официальные SDK для {{ ydb-short-name }} предоставляют встроенные механизмы управления транзакциями и повторным выполнением, упрощающие написание приложений. Используя стандартные механизмы повторного выполнения транзакций из SDK, вы автоматически получаете корректную реализацию логики повторного выполнения без необходимости реализовывать её вручную. Подробнее о механизмах повторного выполнения для различных SDK см. [{#T}](../../reference/ydb-sdk/error_handling.md).
-
-## Язык запросов
-
-Запросы для {{ ydb-short-name }} пишутся на [YQL](../glossary.md#yql) — SQL-диалекте, специально адаптированным для распределённых масштабируемых баз данных. Хотя YQL не полностью совместим с ANSI SQL, он во многом сохраняет знакомый синтаксис и принципы SQL, что облегчает обучение и переход для опытных пользователей SQL. Полная справка по языку приведена в [документации по YQL](../../yql/reference/index.md).
-
-Большинство операций с данными в {{ ydb-short-name }} осуществляется именно через YQL — он является основным инструментом для работы с данными и администрирования базы. Владение YQL позволяет использовать все возможности распределённой архитектуры {{ ydb-short-name }} и реализовывать сложную бизнес-логику непосредственно в запросах.
-
-YQL поддерживает все основные конструкции SQL, в числе которых:
-
-- [Язык манипулирования данными (DML)](https://ru.wikipedia.org/wiki/Язык_манипулирования_данными): `SELECT`, `INSERT`, `REPLACE`, `UPDATE`, `DELETE`, `UPSERT`.
-- [Язык определения данных (DDL)](https://ru.wikipedia.org/wiki/Язык_определения_данных): `CREATE`, `ALTER`, `DROP` для таблиц, индексов и других объектов схемы.
-- Соединения — все стандартные виды соединений, а также специальные типы соединений (например, `LEFT SEMI`, `RIGHT SEMI`, `ANY`).
-- Агрегации — группировка (`GROUP BY`) и оконные функции.
-- [Именованные выражения](../../yql/reference/syntax/expressions.md#named-nodes) для структурирования текста запроса.
-- Большое количество встроенных функций для обработки разных типов данных и решения сложных задач прямо в запросе.
-- Прагмы (pragma) и подсказки (hints) для управления планом выполнения.
-
-## Результирующие наборы
-
-Результатом выполнения запроса в {{ ydb-short-name }} может быть один или несколько результирующих наборов (result sets). Результирующий набор похож на таблицу: он содержит строки со строгой типизацией данных в каждом столбце. Строгая типизация результатов обеспечивает предсказуемость и согласованность формата выдачи.
-
-Результирующие наборы могут содержать произвольно большой объём данных, поэтому для их эффективной передачи {{ ydb-short-name }} использует потоковую выдачу (streaming) — результат возвращается на клиент порциями (chunks). Это позволяет сразу начинать обработку данных без ожидания получения всей выборки и минимизирует использование оперативной памяти клиентским приложением.
-
-## Ограничения
-
-При работе с запросами в {{ ydb-short-name }} важно учитывать ряд ограничений:
-
-* **Отсутствие схемных транзакций**
-{{ ydb-short-name }} не поддерживает схемные транзакции, поэтому DDL-операции (создание или изменение таблиц) нельзя объединять с DML-запросами (вставка, изменение или удаление данных) в одной транзакции или одном запросе.
-
-* **Большие обновления и оптимистичные блокировки**
-{{ ydb-short-name }} применяет механизм оптимистичных блокировок. При попытке выполнить очень большие `UPDATE` или `DELETE` в рамках одной транзакции вероятность конфликтов по блокировкам сильно возрастает, делая такие операции непрактичными для реального использования. Для больших изменений рекомендуется использовать [`BATCH UPDATE`](../../yql/reference/syntax/batch-update.md)/[`BATCH DELETE`](../../yql/reference/syntax/batch-delete.md).
-
-* **Ограничения на размер транзакции**
-Объём данных, записываемых в одной транзакции, ограничен. Подробности см. в разделе [{#T}](../limits-ydb.md#query).
-
-Полный список ограничений системы приведён в [{#T}](../limits-ydb.md).
\ No newline at end of file
+Подробнее см. в разделе [{#T}](../../yql/reference/syntax/select/streaming.md).
diff --git a/ydb/docs/ru/core/concepts/query_execution/toc_i.yaml b/ydb/docs/ru/core/concepts/query_execution/toc_i.yaml
index e7c907f2bb3..247322c094c 100644
--- a/ydb/docs/ru/core/concepts/query_execution/toc_i.yaml
+++ b/ydb/docs/ru/core/concepts/query_execution/toc_i.yaml
@@ -1,6 +1,8 @@
 items:
   - name: Обзор
     href: index.md
+  - name: Процесс выполнения запросов
+    href: execution_process.md
   - name: Оптимизатор запросов
     href: optimizer.md
   - name: Многоверсионное управление конкурентным доступом (MVCC)