morrySnow commented on code in PR #1614:
URL: https://github.com/apache/doris-website/pull/1614#discussion_r1897388425
##########
docs/sql-manual/sql-statements/Data-Manipulation-Statements/Manipulation/EXPLAIN.md:
##########
@@ -0,0 +1,658 @@
+---
+{
+ "title": "EXPLAIN",
+ "language": "en"
+}
+
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+
+## Description
+
+The EXPLAIN statement displays Doris's query execution plan for a given query.
Doris's query optimizer aims to create an efficient plan using statistical
data, data characteristics, and features like HASH JOIN, partitioning, and
bucketing. However, due to theoretical and practical constraints, the plan may
sometimes under perform.
+
+To improve performance, it's essential to analyze the current plan. This
article teaches how to use the EXPLAIN statement for optimization.
+
+
+
+## Syntax
+
+```sql
+{EXPLAIN | DESC} [VERBOSE] <query_block>
+```
+
+## Required Parameters
+
+**<query_block>**
+
+> The query statement for which you want to view the execution plan.
+
+## Optional Parameters
+
+**[VERBOSE]**
+
+> Whether to display detailed information is determined by the `VERBOSE`
specification. With `VERBOSE`, comprehensive details are shown, including
specifics on each operator, the tuple IDs they use, and detailed descriptions
for each tuple. Without it, concise information is provided.
+
+
+## Return Results
+
+### Basic Concepts
+
+To better understand the information displayed by `EXPLAIN`, let's introduce a
few core concepts of the Doris execution plan.
+
+| Name | Explanation |
+| :-------- | :----------------------------------------------------------- |
+| PLAN | Execution plan. A query is translated into an execution plan by
the execution planner, which is then executed by the execution engine. |
+| FRAGMENT | Execution fragment. Since Doris is a distributed execution
engine, a complete execution plan is divided into multiple single-node
execution fragments. A FRAGMENT table represents a complete single-node
execution fragment. Multiple FRAGMENTS combine to form a complete PLAN. |
+| PLAN NODE | Operator. The smallest unit of the execution plan. A FRAGMENT
consists of multiple operators. Each operator is responsible for a specific
execution logic, such as aggregation, joins, etc. |
+
+### Return Result Structure
+
+The result of the Doris `EXPLAIN` statement is a complete PLAN. Within the
PLAN, FRAGMENTS are ordered from back to front based on the execution sequence.
Within each FRAGMENT, operators (PLAN NODES) are also ordered from back to
front based on the execution sequence.
+
+An example is provided below:
+
+
+```sql
++--------------------------------------------------+
+| Explain String(Nereids Planner) |
++--------------------------------------------------+
+| PLAN FRAGMENT 0 |
+| OUTPUT EXPRS: |
+| cnt[#10] |
+| cnt[#11] |
+| PARTITION: UNPARTITIONED |
+| |
+| HAS_COLO_PLAN_NODE: false |
+| |
+| VRESULT SINK |
+| MYSQL_PROTOCAL |
+| |
+| 7:VEXCHANGE |
+| offset: 0 |
+| distribute expr lists: |
+| |
+| PLAN FRAGMENT 1 |
+| |
+| PARTITION: RANDOM |
+| |
+| HAS_COLO_PLAN_NODE: false |
+| |
+| STREAM DATA SINK |
+| EXCHANGE ID: 07 |
+| UNPARTITIONED |
+| |
+| 6:VHASH JOIN(354) |
+| | join op: INNER JOIN(BROADCAST)[] |
+| | equal join conjunct: cnt[#7] = cnt[#5] |
+| | cardinality=1 |
+| | vec output tuple id: 8 |
+| | vIntermediate tuple ids: 7 |
+| | hash output slot ids: 5 7 |
+| | distribute expr lists: |
+| | distribute expr lists: |
+| | |
+| |----4:VEXCHANGE |
+| | offset: 0 |
+| | distribute expr lists: |
+| | |
+| 5:VEXCHANGE |
+| offset: 0 |
+| distribute expr lists: |
+| |
+| PLAN FRAGMENT 2 |
+| ... |
+| |
+| PLAN FRAGMENT 3 |
+| ... |
++--------------------------------------------------+
+```
+
+Operators are linked to their child nodes with dashed lines. When an operator
has multiple children, they are arranged vertically, representing a
right-to-left order. In the example above, operator 6 (VHASH JOIN) has operator
5 (EXCHANGE) as its left child and operator 4 (EXCHANGE) as its right child.
+
+
+### Fragment Field Descriptions
+
+
+| Name | Description
|
+| :----------------- |
:----------------------------------------------------------- |
+| PARTITION | Displays the data distribution of the current Fragment
|
+| HAS_COLO_PLAN_NODE | Indicates if the fragment contains colocate operators
|
+| Sink | The method of fragment data output, see the table below
for details |
+
+
+
+**Sink Methods**
+
+
+| Name | Description
|
+| :----------------- |
:----------------------------------------------------------- |
+| STREAM DATA SINK | Outputs data to the next Fragment. It includes two
lines of information.<br />First line: The downstream EXCHANGE NODE to which
data is sent.<br />Second line: The method of data distribution. UNPARTITIONED
means each downstream instance receives the full data set.<br />This typically
occurs in broadcast joins or when single-instance logic is required, such as
global limit or order by.<br />RANDOM means each downstream instance receives a
random subset of data without repetition.<br />HASH_PARTITIONED uses the listed
slots as keys to hash and send data shards to the same downstream instance.
This is often used upstream of partition hash joins or the second stage of
two-phase aggregations. |
Review Comment:
这里的换行有些问题
```
Second Line
- UNPARTITIONED
- RANDOM
- HASH_PARTITIONED
```
##########
docs/sql-manual/sql-statements/Data-Manipulation-Statements/Manipulation/EXPLAIN.md:
##########
@@ -0,0 +1,658 @@
+---
+{
+ "title": "EXPLAIN",
+ "language": "en"
+}
+
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+
+## Description
+
+The EXPLAIN statement displays Doris's query execution plan for a given query.
Doris's query optimizer aims to create an efficient plan using statistical
data, data characteristics, and features like HASH JOIN, partitioning, and
bucketing. However, due to theoretical and practical constraints, the plan may
sometimes under perform.
+
+To improve performance, it's essential to analyze the current plan. This
article teaches how to use the EXPLAIN statement for optimization.
+
+
+
+## Syntax
+
+```sql
+{EXPLAIN | DESC} [VERBOSE] <query_block>
+```
+
+## Required Parameters
+
+**<query_block>**
+
+> The query statement for which you want to view the execution plan.
Review Comment:
This is the query statement for which you want the explain plan.
##########
docs/sql-manual/sql-statements/Data-Manipulation-Statements/Manipulation/EXPLAIN.md:
##########
@@ -0,0 +1,658 @@
+---
+{
+ "title": "EXPLAIN",
+ "language": "en"
+}
+
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+
+## Description
+
+The EXPLAIN statement displays Doris's query execution plan for a given query.
Doris's query optimizer aims to create an efficient plan using statistical
data, data characteristics, and features like HASH JOIN, partitioning, and
bucketing. However, due to theoretical and practical constraints, the plan may
sometimes under perform.
+
+To improve performance, it's essential to analyze the current plan. This
article teaches how to use the EXPLAIN statement for optimization.
+
+
+
+## Syntax
+
+```sql
+{EXPLAIN | DESC} [VERBOSE] <query_block>
+```
+
+## Required Parameters
+
+**<query_block>**
+
+> The query statement for which you want to view the execution plan.
+
+## Optional Parameters
+
+**[VERBOSE]**
+
+> Whether to display detailed information is determined by the `VERBOSE`
specification. With `VERBOSE`, comprehensive details are shown, including
specifics on each operator, the tuple IDs they use, and detailed descriptions
for each tuple. Without it, concise information is provided.
+
+
+## Return Results
+
+### Basic Concepts
+
+To better understand the information displayed by `EXPLAIN`, let's introduce a
few core concepts of the Doris execution plan.
+
+| Name | Explanation |
+| :-------- | :----------------------------------------------------------- |
+| PLAN | Execution plan. A query is translated into an execution plan by
the execution planner, which is then executed by the execution engine. |
+| FRAGMENT | Execution fragment. Since Doris is a distributed execution
engine, a complete execution plan is divided into multiple single-node
execution fragments. A FRAGMENT table represents a complete single-node
execution fragment. Multiple FRAGMENTS combine to form a complete PLAN. |
+| PLAN NODE | Operator. The smallest unit of the execution plan. A FRAGMENT
consists of multiple operators. Each operator is responsible for a specific
execution logic, such as aggregation, joins, etc. |
+
+### Return Result Structure
+
+The result of the Doris `EXPLAIN` statement is a complete PLAN. Within the
PLAN, FRAGMENTS are ordered from back to front based on the execution sequence.
Within each FRAGMENT, operators (PLAN NODES) are also ordered from back to
front based on the execution sequence.
+
+An example is provided below:
+
+
+```sql
++--------------------------------------------------+
+| Explain String(Nereids Planner) |
++--------------------------------------------------+
+| PLAN FRAGMENT 0 |
+| OUTPUT EXPRS: |
+| cnt[#10] |
+| cnt[#11] |
+| PARTITION: UNPARTITIONED |
+| |
+| HAS_COLO_PLAN_NODE: false |
+| |
+| VRESULT SINK |
+| MYSQL_PROTOCAL |
+| |
+| 7:VEXCHANGE |
+| offset: 0 |
+| distribute expr lists: |
+| |
+| PLAN FRAGMENT 1 |
+| |
+| PARTITION: RANDOM |
+| |
+| HAS_COLO_PLAN_NODE: false |
+| |
+| STREAM DATA SINK |
+| EXCHANGE ID: 07 |
+| UNPARTITIONED |
+| |
+| 6:VHASH JOIN(354) |
+| | join op: INNER JOIN(BROADCAST)[] |
+| | equal join conjunct: cnt[#7] = cnt[#5] |
+| | cardinality=1 |
+| | vec output tuple id: 8 |
+| | vIntermediate tuple ids: 7 |
+| | hash output slot ids: 5 7 |
+| | distribute expr lists: |
+| | distribute expr lists: |
+| | |
+| |----4:VEXCHANGE |
+| | offset: 0 |
+| | distribute expr lists: |
+| | |
+| 5:VEXCHANGE |
+| offset: 0 |
+| distribute expr lists: |
+| |
+| PLAN FRAGMENT 2 |
+| ... |
+| |
+| PLAN FRAGMENT 3 |
+| ... |
++--------------------------------------------------+
+```
+
+Operators are linked to their child nodes with dashed lines. When an operator
has multiple children, they are arranged vertically, representing a
right-to-left order. In the example above, operator 6 (VHASH JOIN) has operator
5 (EXCHANGE) as its left child and operator 4 (EXCHANGE) as its right child.
+
+
+### Fragment Field Descriptions
+
+
+| Name | Description
|
+| :----------------- |
:----------------------------------------------------------- |
+| PARTITION | Displays the data distribution of the current Fragment
|
+| HAS_COLO_PLAN_NODE | Indicates if the fragment contains colocate operators
|
+| Sink | The method of fragment data output, see the table below
for details |
+
+
+
+**Sink Methods**
+
+
+| Name | Description
|
+| :----------------- |
:----------------------------------------------------------- |
+| STREAM DATA SINK | Outputs data to the next Fragment. It includes two
lines of information.<br />First line: The downstream EXCHANGE NODE to which
data is sent.<br />Second line: The method of data distribution. UNPARTITIONED
means each downstream instance receives the full data set.<br />This typically
occurs in broadcast joins or when single-instance logic is required, such as
global limit or order by.<br />RANDOM means each downstream instance receives a
random subset of data without repetition.<br />HASH_PARTITIONED uses the listed
slots as keys to hash and send data shards to the same downstream instance.
This is often used upstream of partition hash joins or the second stage of
two-phase aggregations. |
+| RESULT SINK | Sends result data to the FE. The first line indicates
the protocol used for data transmission, currently supporting MySQL and arrow
protocols. |
+| OLAP TABLE SINK | Writes data to an OLAP table.
|
+| MultiCastDataSinks | A multicast operator that contains multiple STREAM DATA
SINKs. Each STREAM DATA SINK sends the full data set to its downstream. |
+
+
+
+### Tuple Information Description
+
+When using VERBOSE mode, Tuple information is output. Tuple information
describes the SLOT details within a row of data, including SLOT type, nullable
status, etc.
+
+The output contains multiple TupleDescriptors, each containing multiple
SlotDescriptors. An example is shown below:
+
+```sql
+Tuples:
+TupleDescriptor{id=0, tbl=t1}
+ SlotDescriptor{id=0, col=c1, colUniqueId=0, type=int, nullable=true,
isAutoIncrement=false, subColPath=null}
+ SlotDescriptor{id=2, col=c3, colUniqueId=2, type=int, nullable=true,
isAutoIncrement=false, subColPath=null}
+```
+
+#### TupleDescriptor
+
+
+
+| Name | Description |
+| :--- | :----------------------------------------------------------- |
+| id | The id of the tuple descriptor |
+| tbl | The corresponding table of the tuple, or left blank if not applicable
|
+
+
+
+#### SlotDescriptor
+
+| Name | Description
|
+| :-------------- |
:----------------------------------------------------------- |
+| id | The id of the slot descriptor
|
+| col | The corresponding column of the slot, or left blank if not
applicable |
Review Comment:
null
##########
docs/sql-manual/sql-statements/Data-Manipulation-Statements/Manipulation/EXPLAIN.md:
##########
@@ -0,0 +1,658 @@
+---
+{
+ "title": "EXPLAIN",
+ "language": "en"
+}
+
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+
+## Description
+
+The EXPLAIN statement displays Doris's query execution plan for a given query.
Doris's query optimizer aims to create an efficient plan using statistical
data, data characteristics, and features like HASH JOIN, partitioning, and
bucketing. However, due to theoretical and practical constraints, the plan may
sometimes under perform.
+
+To improve performance, it's essential to analyze the current plan. This
article teaches how to use the EXPLAIN statement for optimization.
+
+
+
+## Syntax
+
+```sql
+{EXPLAIN | DESC} [VERBOSE] <query_block>
+```
+
+## Required Parameters
+
+**<query_block>**
+
+> The query statement for which you want to view the execution plan.
+
+## Optional Parameters
+
+**[VERBOSE]**
+
+> Whether to display detailed information is determined by the `VERBOSE`
specification. With `VERBOSE`, comprehensive details are shown, including
specifics on each operator, the tuple IDs they use, and detailed descriptions
for each tuple. Without it, concise information is provided.
+
+
+## Return Results
+
+### Basic Concepts
+
+To better understand the information displayed by `EXPLAIN`, let's introduce a
few core concepts of the Doris execution plan.
+
+| Name | Explanation |
+| :-------- | :----------------------------------------------------------- |
+| PLAN | Execution plan. A query is translated into an execution plan by
the execution planner, which is then executed by the execution engine. |
+| FRAGMENT | Execution fragment. Since Doris is a distributed execution
engine, a complete execution plan is divided into multiple single-node
execution fragments. A FRAGMENT table represents a complete single-node
execution fragment. Multiple FRAGMENTS combine to form a complete PLAN. |
+| PLAN NODE | Operator. The smallest unit of the execution plan. A FRAGMENT
consists of multiple operators. Each operator is responsible for a specific
execution logic, such as aggregation, joins, etc. |
+
+### Return Result Structure
+
+The result of the Doris `EXPLAIN` statement is a complete PLAN. Within the
PLAN, FRAGMENTS are ordered from back to front based on the execution sequence.
Within each FRAGMENT, operators (PLAN NODES) are also ordered from back to
front based on the execution sequence.
+
+An example is provided below:
+
+
+```sql
++--------------------------------------------------+
+| Explain String(Nereids Planner) |
++--------------------------------------------------+
+| PLAN FRAGMENT 0 |
+| OUTPUT EXPRS: |
+| cnt[#10] |
+| cnt[#11] |
+| PARTITION: UNPARTITIONED |
+| |
+| HAS_COLO_PLAN_NODE: false |
+| |
+| VRESULT SINK |
+| MYSQL_PROTOCAL |
+| |
+| 7:VEXCHANGE |
+| offset: 0 |
+| distribute expr lists: |
+| |
+| PLAN FRAGMENT 1 |
+| |
+| PARTITION: RANDOM |
+| |
+| HAS_COLO_PLAN_NODE: false |
+| |
+| STREAM DATA SINK |
+| EXCHANGE ID: 07 |
+| UNPARTITIONED |
+| |
+| 6:VHASH JOIN(354) |
+| | join op: INNER JOIN(BROADCAST)[] |
+| | equal join conjunct: cnt[#7] = cnt[#5] |
+| | cardinality=1 |
+| | vec output tuple id: 8 |
+| | vIntermediate tuple ids: 7 |
+| | hash output slot ids: 5 7 |
+| | distribute expr lists: |
+| | distribute expr lists: |
+| | |
+| |----4:VEXCHANGE |
+| | offset: 0 |
+| | distribute expr lists: |
+| | |
+| 5:VEXCHANGE |
+| offset: 0 |
+| distribute expr lists: |
+| |
+| PLAN FRAGMENT 2 |
+| ... |
+| |
+| PLAN FRAGMENT 3 |
+| ... |
++--------------------------------------------------+
+```
+
+Operators are linked to their child nodes with dashed lines. When an operator
has multiple children, they are arranged vertically, representing a
right-to-left order. In the example above, operator 6 (VHASH JOIN) has operator
5 (EXCHANGE) as its left child and operator 4 (EXCHANGE) as its right child.
+
+
+### Fragment Field Descriptions
+
+
+| Name | Description
|
+| :----------------- |
:----------------------------------------------------------- |
+| PARTITION | Displays the data distribution of the current Fragment
|
+| HAS_COLO_PLAN_NODE | Indicates if the fragment contains colocate operators
|
+| Sink | The method of fragment data output, see the table below
for details |
+
+
+
+**Sink Methods**
+
+
+| Name | Description
|
+| :----------------- |
:----------------------------------------------------------- |
+| STREAM DATA SINK | Outputs data to the next Fragment. It includes two
lines of information.<br />First line: The downstream EXCHANGE NODE to which
data is sent.<br />Second line: The method of data distribution. UNPARTITIONED
means each downstream instance receives the full data set.<br />This typically
occurs in broadcast joins or when single-instance logic is required, such as
global limit or order by.<br />RANDOM means each downstream instance receives a
random subset of data without repetition.<br />HASH_PARTITIONED uses the listed
slots as keys to hash and send data shards to the same downstream instance.
This is often used upstream of partition hash joins or the second stage of
two-phase aggregations. |
+| RESULT SINK | Sends result data to the FE. The first line indicates
the protocol used for data transmission, currently supporting MySQL and arrow
protocols. |
+| OLAP TABLE SINK | Writes data to an OLAP table.
|
+| MultiCastDataSinks | A multicast operator that contains multiple STREAM DATA
SINKs. Each STREAM DATA SINK sends the full data set to its downstream. |
+
+
+
+### Tuple Information Description
+
+When using VERBOSE mode, Tuple information is output. Tuple information
describes the SLOT details within a row of data, including SLOT type, nullable
status, etc.
+
+The output contains multiple TupleDescriptors, each containing multiple
SlotDescriptors. An example is shown below:
+
+```sql
+Tuples:
+TupleDescriptor{id=0, tbl=t1}
+ SlotDescriptor{id=0, col=c1, colUniqueId=0, type=int, nullable=true,
isAutoIncrement=false, subColPath=null}
+ SlotDescriptor{id=2, col=c3, colUniqueId=2, type=int, nullable=true,
isAutoIncrement=false, subColPath=null}
+```
+
+#### TupleDescriptor
+
+
+
+| Name | Description |
+| :--- | :----------------------------------------------------------- |
+| id | The id of the tuple descriptor |
+| tbl | The corresponding table of the tuple, or left blank if not applicable
|
Review Comment:
```suggestion
| tbl | The corresponding table of the tuple, or 1null` if not applicable |
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
