[DOC-12349] Update Query Execution Diagram

modules/indexes/pages/index-scans.adoc

@@ -23,6 +23,7 @@ The Query node analyzes the query, uses metadata on underlying objects to figure
 During execution, depending on the query, using applicable indexes, the Query node works with the Index and Data nodes to retrieve and perform the planned operations.
 Because Couchbase is a modular clustered database, you scale out data, index, and query services to fit your performance and availability goals.
 
+.Query Execution Overview
 [plantuml,query-execution,svg]
 ....
 include::partial$diagrams/query-execution.puml[]
@@ -33,19 +34,23 @@ include::partial$diagrams/query-execution.puml[]
 
 The following figure shows all the possible phases a SELECT query goes through to return the results.
 Not all queries need to go through every phase, some go through many of these phases multiple times.
-For example, the Sort phase can be skipped when there is no ORDER BY clause in the query; and the Scan-Fetch-Join phases will execute multiple times for correlated subqueries.
+For example, the Query Service skips the Sort phase when it does not include an ORDER BY clause; and the Scan-Fetch-Join phases execute multiple times for correlated subqueries.
 
+.Query Execution Phases
 [plantuml,query-service,svg]
 ....
 include::partial$diagrams/query-service.puml[]
 ....
 
-http://blog.couchbase.com/sql-for-documents-n1ql-brief-introduction-to-query-planning[This brief introduction to query planning^] has details of query planner.
-When the Index path is chosen, query engine requests the scan by providing the range of values to return.
-This range is represented as a SPAN in the query plan.
-The index spans will play major roles in optimal plan generation and execution.
-Here, we discuss how the Index spans are generated from the query predicates (filters).
+During query execution, the query planner selects the most appropriate index path based on the query predicates (filters). 
+Once the index path is chosen, the query engine requests the Index Service to perform a scan. 
+This scan is defined by a specific range of values that the query engine needs to retrieve. 
+These ranges are represented as spans in the query plan. 
+A span defines the start and end values for the scan, along with whether these values are inclusive or exclusive. 
+It plays a critical role in optimizing both the query plan generation and its execution. 
+For more information about index spans, see <<spans-overview>>.
 
+[[spans-overview]]
 == Spans Overview
 
 FILTER, JOIN, and PROJECT are fundamental operations of database query processing.

modules/indexes/partials/diagrams/query-service.puml

@@ -76,6 +76,15 @@ rectangle "Query Service"{
 
 
 
+  ]
+  rectangle Project [
+    Project
+
+
+    ▢
+    ▢
+    ▢
+    ▢
   ]
   rectangle Sort [
     Sort
@@ -104,14 +113,14 @@ rectangle "Query Service"{
 
 
   ]
-  rectangle Project [
-    Project
+  rectangle Stream [
+    Stream
 
 
     ▢
-    ▢
-    ▢
-    ▢
+
+
+
   ]
 }
 
@@ -129,15 +138,19 @@ Fetch -> Join
 Join -> Filter
 Filter -> PreAggregate
 PreAggregate -> Aggregate
-Aggregate -> Sort
+Aggregate -> Project
+Project -> Sort
 Sort -> Offset
 Offset -> Limit
-Limit -> Project
-Project .u.> End
+Limit -> Stream
+Stream .u.> End
 
-Scan .. Index
-Scan .. Search
+Scan ... Index
+Scan ... Search
 Fetch .. Data
 Join .. Data
+Join .. Index
+Join .. Search
+
 
 @enduml

modules/n1ql/pages/n1ql-language-reference/selectintro.adoc

@@ -167,15 +167,16 @@ For example, sort phase can be skipped when there is no ORDER BY clause in the q
 
 The following diagram shows the possible elements and operations during query execution.
 
+[[query-execution-phases]]
 .Query Execution Phases
 [plantuml,query-service,svg]
 ....
 include::indexes:partial$diagrams/query-service.puml[]
 ....
 
-Some phases are done serially while others are done in parallel, as specified by their parent operator.
+Some phases execute serially, while others execute in parallel, as determined by their parent operator.
 
-The below table summarizes all the Query Phases that might be used in an Execution Plan:
+The following table summarizes all the Query Phases used in an Execution Plan:
 
 [cols="1,4"]
 |===
@@ -185,7 +186,7 @@ The below table summarizes all the Query Phases that might be used in an Executi
 | Analyzes the query and available access path options for each keyspace in the query to create a query plan and execution infrastructure.
 
 | Plan
-| Selects the access path, determines the Join order, determines the type of Joins, and then creates the infrastructure needed to execute the plan.
+| Selects the access path, determines the join order and join types, and then creates the infrastructure needed to execute the plan.
 
 | Scan
 | Scans the data from the Index Service.
@@ -205,17 +206,21 @@ The below table summarizes all the Query Phases that might be used in an Executi
 | Aggregate
 | Performs aggregating functions and window functions.
 
+| Project
+| Retrieves only the fields required for the client.
+
 | Sort
-| Orders and sorts items in the resultset in the order specified by the ORDER BY clause
+| Orders and sorts items in the result set in the order specified by the ORDER BY clause. 
 
 | Offset
 | Skips the first _n_ items in the result object as specified by the OFFSET clause.
 
 | Limit
 | Limits the number of results returned using the LIMIT clause.
 
-| Project
-| Receives only the fields needed for final displaying to the user.
+| Stream
+| Streams the final results back to the client.
+
 |===
 
 The possible elements and operations in a query include: