alex-plekhanov commented on code in PR #10983: URL: https://github.com/apache/ignite/pull/10983#discussion_r1356733426
########## docs/_docs/sql-reference/hints.adoc: ########## @@ -0,0 +1,17 @@ +// 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. += Optimizer hints Review Comment: Is there any reference to this file? Why do we need it? ########## docs/_docs/SQL/sql-calcite.adoc: ########## @@ -241,3 +228,152 @@ Below are the data types supported by the Calcite-based SQL engine: |`java.lang.Object` |=== + +== Optimizer hints [[hints]] + +The query optimizer does its best to build the fastest excution plan. But it is a far way to create an optimizer which +is the most effective for each case. You may have better knowledge of your data design, application design or data +distribution in the cluster. The SQL hints can help the optimizer to make optimizations more rationally or build +execution plan faster. + +[NOTE] +==== +SQL hints are not mandatory to apply and might be skipped by. Especially in case of a long, complex query or if +a hint is defined deep inside a query. +==== + +=== Hints format +Sql hints are defined with the special comment +++/*+ HINT */+++ reffered as _hint block_. Spaces before and after the +hint name are required. Hint block is placed right after a relation operator. Usually, after _SELECT_. Several hint +blocks for one relation operator *are not allowed*. + +Example: +[source, SQL] +---- +SELECT /*+ NO_INDEX */ T1.* FROM TBL1 where T1.V1=? and T1.V2=? +---- + +It is allowed to define several hints for the same relation operator. For that, hints are separated with comma +(spaces are optional). + +Example: +[source, SQL] +---- +SELECT /*+ NO_INDEX, EXPAND_DISTINCT_AGG */ SUM(DISTINCT V1), AVG(DISTINCT V2) FROM TBL1 GROUP BY V3 WHERE V3=? +---- + +==== Hint parameters +Currently, only simple, plain hint parameters are supported (no key-value). Hint parameters, if required, are placed Review Comment: Let's remove `Currently, only simple, plain hint parameters are supported (no key-value).` User doesn't know about key-value format, so it can be a liitle bit confusing. ########## docs/_docs/SQL/sql-calcite.adoc: ########## @@ -241,3 +228,152 @@ Below are the data types supported by the Calcite-based SQL engine: |`java.lang.Object` |=== + +== Optimizer hints [[hints]] + +The query optimizer does its best to build the fastest excution plan. But it is a far way to create an optimizer which +is the most effective for each case. You may have better knowledge of your data design, application design or data +distribution in the cluster. The SQL hints can help the optimizer to make optimizations more rationally or build +execution plan faster. + +[NOTE] +==== +SQL hints are not mandatory to apply and might be skipped by. Especially in case of a long, complex query or if Review Comment: Let's remove `Especially in case of a long, complex query or if a hint is defined deep inside a query.`, it's hard to describe all the cases when hints will be skipped, so let's just say `in some cases`. -- 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]
