这是本节的多页打印视图。点击此处打印.

提示

1: :c
2: :v
3: ALLNODES
4: DEPOT_FETCH
5: DISTRIB
6: EARLY_MATERIALIZATION
7: ECSMODE
8: ENABLE_WITH_CLAUSE_MATERIALIZATION
9: GBYTYPE
10: JFMT
11: JTYPE
12: LABEL
13: PROJS
14: SKIP_PROJS
15: SKIP_STATISTICS
16: SYNTACTIC_JOIN
17: UTYPE
18: VERBATIM

提示是您嵌入到查询或定向查询中的指令。这些指令符合以下语法：

/*+hint-name[, hint-name]...*/

用注释字符 /*+ 和 */ 括住提示，这种方式可以括住多个用逗号分隔的提示。例如：

SELECT /*+syntactic_join,verbatim*/

限制

在查询中嵌入提示时，请注意以下限制：

不要在注释字符 /* 和 */ 中嵌入空格。
通常，允许在加号 (+) 字符和 hint‑name 前后使用空格；但是，某些第三方工具不支持在 /*+ 中嵌入空格。

支持的提示

Vertica 支持以下提示：

一般提示

Eon 模式提示

联接提示

投影提示

定向查询提示

以下提示仅通过定向查询提供支持：

1 - :c

在定向查询中，标记必须包含在输入查询中的查询常量；否则，将取消该输入查询使用定向查询的资格。

语法

/*+:c*/

使用

默认情况下，优化器生成的定向查询集忽略谓词常量的常量 (:v) 提示。您可以通过在不得忽略的输入查询常量上设置 :c 提示来覆盖此行为。例如，以下语句创建了一个定向查询，该查询只能用于联接谓词常量与原始输入查询相同的输入查询 — 8：

=> CREATE DIRECTED QUERY OPTIMIZER simpleJoin_KeepPredicateConstant SELECT * FROM S JOIN T ON S.a = T.b WHERE S.a = 8 /*+:c*/;
CREATE DIRECTED QUERY
=> ACTIVATE DIRECTED QUERY simpleJoin_KeepPredicateConstant;

另请参阅

保留定向查询中的谓词常量

2 - :v

在定向查询中，标记优化器在考虑是否对给定查询使用定向查询时忽略的输入查询常量。使用此提示创建可对输入查询的多个变体使用的定向查询。

Vertica 还支持将 IGNORECONST 作为 :v 的别名。优化器生成的定向查询会自动在输入和带注释的查询中标记谓词常量并附带 :v 提示。

有关详细信息，请参阅忽略定向查询中的常量。

语法

/*+:v(arg)*/

/*+IGNORECONST(arg)*/

arg: 为将每个输入查询 :v 提示与一个或多个带注释的查询 :v 提示配对而在定向查询中使用的整数实参。

示例

请参阅忽略定向查询中的常量。

3 - ALLNODES

限定 EXPLAIN 语句请求假设所有节点均处于活动状态的查询计划。如果忽略此提示，EXPLAIN 语句将生成一个查询计划，将当前处于关闭状态的任何节点考虑在内。

语法

EXPLAIN /*+ALLNODES*/

示例

在以下示例中，ALLNODES 提示将请求假设所有节点均处于活动状态的查询计划。

QUERY PLAN DESCRIPTION:
 ------------------------------

 Opt Vertica Options
 --------------------
 PLAN_ALL_NODES_ACTIVE


 EXPLAIN /*+ALLNODES*/ select * from Emp_Dimension;

 Access Path:
 +-STORAGE ACCESS for Emp_Dimension [Cost: 125, Rows: 10K (NO STATISTICS)] (PATH ID: 1)
 |  Projection: public.Emp_Dimension_b0
 |  Materialize: Emp_Dimension.Employee_key, Emp_Dimension.Employee_gender, Emp_Dimension.Courtesy_title, Emp_Dimension.Employee_first_name, Emp_Dimension.Employee_middle_initial, Emp_Dimension.Employee_last_name, Emp_Dimension.Employee_age, Emp_Dimension.Employee_birthdate, Emp_Dimension.Employee_street, Emp_Dimension.Employee_city, Emp_Dimension.Employee_state, Emp_Dimension.Employee_region, Emp_Dimension.Employee_position
 |  Execute on: All Nodes

4 - DEPOT_FETCH

仅限 Eon 模式

当存储库缺少此查询的数据时，指定查询是否从公共存储将数据提取到存储库中。此提示会覆盖配置参数 DepotOperationsForQuery。

语法

SELECT /*+DEPOT_FETCH (option)*/

参数

可选

指定当存储库不包含查询的文件数据时的行为，为以下之一：

ALL （默认值）：从公共存储中提取文件数据，如有必要，通过将现有文件从存储库中逐出来替换它们。
FETCHES：仅当空间可用时才从公共存储中提取文件数据；否则，直接从公共存储中读取查询的数据。
NONE：请勿将文件数据提取到存储库，而应直接从公共存储中读取查询的数据。

示例

SELECT /*+DEPOT_FETCH(All)*/ count(*) FROM bar;
SELECT /*+DEPOT_FETCH(FETCHES)*/ count(*) FROM bar;
SELECT /*+DEPOT_FETCH(NONE)*/ count(*) FROM bar;

5 - DISTRIB

指定优化器如何分发联接键以实施联接。

语法

JOIN /*+DISTRIB(outer-join, inner-join)*/

参数

外联接 内联接

指定如何分发外联接和内连接上的数据：

L （当地）：在各节点上对内联接键和外联接键进行相同分段，本地联接。
R （重新分段）：内部和外部联接键没有进行相同分段。实施联接前对联接键数据进行重新分段。
B （广播）：内部和外部联接键没有进行相同分段。实施联接前将此联接键的数据广播至其他节点。
F （筛选）：联接表未分段。实施联接前根据需要按其他联接键筛选数据。
A （任意）：让优化器自行选择最有效的分发方法。

描述

DISTRIB 提示指定优化器如何按顺序分发联接键以实施联接。如果指定的分发方法不可行，优化器会忽略提示并发出警告。

需要满足以下要求：

包含 DISTRIB 提示的查询必须也包含 SYNTACTIC_JOIN 提示。否则，优化器会忽略 DISTRIB 提示并抛出一条警告。
联接语法必须符合 ANSI SQL-92 联接约定。

示例

在以下查询中，联接受 DISTRIB 的提示 /*+DISTRIB(L,R)*/ 限定。此提示指示优化器先对联接键 stores.store_key 的数据进行重新分段，然后再将其联接至 sales.store_key 数据：

SELECT /*+SYNTACTIC_JOIN*/ sales.store_key, stores.store_name, sales.product_description, sales.sales_quantity, sales.sale_date
FROM (store.storeSales AS sales JOIN /*+DISTRIB(L,R),JTYPE(H)*/ store.store_dimension AS stores ON (sales.store_key = stores.store_key))
WHERE (sales.sale_date = '2014-12-01'::date) ORDER BY sales.store_key, sales.sale_date;

6 - EARLY_MATERIALIZATION

为当前查询指定表的早期实体化。一个查询可以针对任意数量的表包含这项提示。通常，查询优化器会将实体化延迟到查询执行流程后期。此提示会覆盖优化器通过其他方式做出的任何选择。

如果后续实体化联接输入会妨碍其他优化 — 例如，将聚合下推到联接，或使用实时聚合投影，此提示可能会非常有用。在这些情况下，使用 EARLY_MATERIALIZATION 限定联接输入可以启用优化。

语法

table-name [ [AS] alias ] /*+EARLY_MATERIALIZATION*/

7 - ECSMODE

仅限 Eon 模式

设置优化器在订户节点之间划分分片数据处理职责时使用的 ECS 策略。仅当子群集使用弹性处理调整 (ECS) 时才会应用此提示。

语法

SELECT /*+ECSMODE(option)*/

参数

可选

指定在其订阅节点之间划分分片数据时使用的策略，为以下之一：

AUTO：优化器选择要使用的策略，仅当在会话级别设置 ECS 模式时才有用（请参阅为会话或数据库设置 ECS 策略）。
IO_OPTIMIZED：使用 I/O 优化策略。
COMPUTE_OPTIMIZED：使用计算优化策略。
NONE：对此查询禁用 ECS。只有参与节点才会涉及查询执行；协作节点不会涉及。

示例

以下示例显示了简单的单表查询（被强制使用计算优化策略）的查询计划：

=> EXPLAIN SELECT /*+ECSMode(COMPUTE_OPTIMIZED)*/ employee_last_name,
             employee_first_name,employee_age
             FROM employee_dimension
             ORDER BY employee_age DESC;

                                   QUERY PLAN
--------------------------------------------------------------------------------
 ------------------------------
 QUERY PLAN DESCRIPTION:
 The execution of this query involves non-participating nodes.
 Crunch scaling strategy preserves data segmentation
 ------------------------------
. . .

8 - ENABLE_WITH_CLAUSE_MATERIALIZATION

启用当前 WITH 子句中所有查询的实体化。否则，实体化由配置参数 WithClauseMaterialization 设置，默认设置为 0（禁用）。如果禁用 WithClauseMaterialization，则 WITH 子句的主查询返回时会自动清除实体化。有关详细信息，请参阅WITH 子句的实体化。

语法

WITH /*+ENABLE_WITH_CLAUSE_MATERIALIZATION*/

9 - GBYTYPE

指定 Vertica 查询优化器应使用哪一种算法（GROUPBY HASH 或 GROUPBY PIPELINED）实施 GROUP BY 子句。如果两种算法对此查询都有效，则查询优化器会优先选择指定的算法，而不是查询优化器可能通过其他方式在其查询计划中选择的算法。

语法

GROUP BY /*+GBYTYPE( HASH | PIPE )*/

参数

HASH | PIPE

指定要使用的 GROUP BY 算法：

HASH：GROUPBY HASH 算法
PIPE：GROUPBY PIPELINED 算法

注意
仅当查询及其投影之一符合 GROUPBY PIPELINED 要求时，Vertica 才会使用 GROUPBY PIPELINED 算法。否则，Vertica 会发出警告并使用 GROUPBY HASH。

有关两种算法的详细信息，请参阅 GROUP BY 实施选项。

示例

请参阅控制 GROUPBY 算法选项。

10 - JFMT

指定联接这些列中的表时如何调整 VARCHAR 列数据的大小并相应缓冲数据。JFMT 提示覆盖由配置参数 JoinDefaultTupleFormat 设置的默认行为，可在数据库和会话级别进行设置。

有关详细信息，请参阅联接可变长度字符串数据。

语法

JOIN /*+JFMT(format-type)*/

参数

format‑type

指定联接这些列中的表时如何设置 VARCHAR 列数据的格式并相应缓冲数据。设置为以下值之一：

f （固定）：使用联接列元数据将列数据的大小调整为固定长度，并相应地进行缓冲。
v （变量）：使用联接列数据的实际长度，因此每个联接的缓冲区大小不同。

例如：

SELECT /*+SYNTACTIC_JOIN*/ s.store_region, SUM(e.vacation_days) TotalVacationDays
   FROM public.employee_dimension e
   JOIN /*+JFMT(f)*/ store.store_dimension s ON s.store_region=e.employee_region
   GROUP BY s.store_region ORDER BY TotalVacationDays;

要求

包含 JFMT 提示的查询必须也包含 SYNTACTIC_JOIN 提示。否则，优化器会忽略 JFMT 提示并抛出一条警告。
联接语法必须符合 ANSI SQL-92 联接约定。

11 - JTYPE

指定联接算法是哈希联接还是合并联接。

使用 JTYPE 提示以指定优化器用来联接表数据的算法。如果指定算法不可行，优化器将忽略提示并发出警告。

语法

JOIN /*+JTYPE(join-type)*/

参数

联接类型

以下几项之一：

H：哈希联接
M：合并联接仅在联接列的输入均排序的情况下有效，否则 Vertica 会忽略并发出警告。优化器依靠查询或 DDL 来验证输入数据是否已排序，而不是依靠数据的实际运行时顺序。
FM：强制合并联接合并前，优化器会重新针对联接输入进行排序。联接列必须是相同的类型、精度或小数位数，但字符串列可以是不同的长度。

FM 的值仅对简单的联接状态有效。例如：

=> SELECT /*+SYNTACTIC_JOIN*/ * FROM x JOIN /*+JTYPE(FM)*/ y ON x.c1 = y.c1;

要求

包含 JTYPE 提示的查询必须也包含 SYNTACTIC_JOIN 提示。否则，优化器会忽略 JTYPE 提示并抛出一条警告。
联接语法必须符合 ANSI SQL-92 联接约定。

12 - LABEL

为语句分配标签，以便轻松识别标签，评估性能和调试问题。

LABEL 提示在以下语句中有效：

COPY
DELETE
EXPORT 语句：
INSERT
MERGE
SELECT
UPDATE
UNION：在 UNION 的第一个 SELECT 语句中有效。Vertica 会忽略后续 SELECT 语句中的标签。

语法

statement-name /*+LABEL (label‑string)*/

参数

标签字串: 最长为 128 个八位字节的字符串。如果用单引号括起，label-string 可以包含嵌入空格。

示例

请参阅标记语句。

13 - PROJS

指定要用于查询的表的一个或多个投影。

语法

FROM table-name /*+PROJS( [[database.]schema.]projection[,...] )*/

参数

[database.]schema: 数据库和架构。默认架构为 public。如果指定一个数据库，它必须是当前数据库。
projection: 要使用的投影。可以指定逗号分隔投影的列表。

描述

PROJS 提示可指定多个投射；优化器指定了哪些有效并使用已查询表中最低成本的一个。如果没有有效的已提示投影，则查询将返回警告并忽略投影提示。

示例

employee_dimension 表包含两个投影：分段的超投影public.employee_dimension，包括所有表列；未分段的投影 public.employee_dimension_rep，包括列的子集：


=> SELECT export_objects('','employee_dimension');
                                                      export_objects
--------------------------------------------------------------------------------------------------------------------------

CREATE TABLE public.employee_dimension
(
    employee_key int NOT NULL,
    employee_gender varchar(8),
    courtesy_title varchar(8),
    employee_first_name varchar(64),
    employee_middle_initial varchar(8),
    employee_last_name varchar(64),
    employee_age int,
    hire_date date,
    employee_street_address varchar(256),
    employee_city varchar(64),
    employee_state char(2),
    employee_region char(32),
    job_title varchar(64),
    reports_to int,
    salaried_flag int,
    annual_salary int,
    hourly_rate float,
    vacation_days int,
    CONSTRAINT C_PRIMARY PRIMARY KEY (employee_key) DISABLED
);

CREATE PROJECTION public.employee_dimension
...
AS
 SELECT employee_dimension.employee_key,
        employee_dimension.employee_gender,
        employee_dimension.courtesy_title,
        employee_dimension.employee_first_name,
        employee_dimension.employee_middle_initial,
        employee_dimension.employee_last_name,
        employee_dimension.employee_age,
        employee_dimension.hire_date,
        employee_dimension.employee_street_address,
        employee_dimension.employee_city,
        employee_dimension.employee_state,
        employee_dimension.employee_region,
        employee_dimension.job_title,
        employee_dimension.reports_to,
        employee_dimension.salaried_flag,
        employee_dimension.annual_salary,
        employee_dimension.hourly_rate,
        employee_dimension.vacation_days
 FROM public.employee_dimension
 ORDER BY employee_dimension.employee_key
SEGMENTED BY hash(employee_dimension.employee_key) ALL NODES KSAFE 1;

CREATE PROJECTION public.employee_dimension_rep
...
AS
 SELECT employee_dimension.employee_key,
        employee_dimension.employee_gender,
        employee_dimension.employee_first_name,
        employee_dimension.employee_middle_initial,
        employee_dimension.employee_last_name,
        employee_dimension.employee_age,
        employee_dimension.employee_street_address,
        employee_dimension.employee_city,
        employee_dimension.employee_state,
        employee_dimension.employee_region
 FROM public.employee_dimension
 ORDER BY employee_dimension.employee_key
UNSEGMENTED ALL NODES;

SELECT MARK_DESIGN_KSAFE(1);

(1 row)

以下查询从 employee_dimension 选择所有表列并包含 PROJS 提示，指定两个投影。 public.employee_dimension_rep 未包含查询表中的所有列，因此优化器无法使用它。分段的投影包含了所有表列，因此优化器可以使用它，已经以下查询计划验证：

=> EXPLAIN SELECT * FROM employee_dimension /*+PROJS('public.employee_dimension_rep', 'public.employee_dimension')*/;

QUERY PLAN DESCRIPTION:
------------------------------
EXPLAIN SELECT * FROM employee_dimension /*+PROJS('public.employee_dimension_rep', 'public.employee_dimension')*/;

 Access Path:
 +-STORAGE ACCESS for employee_dimension [Cost: 177, Rows: 10K (NO STATISTICS)] (PATH ID: 1)
 |  Projection: public.employee_dimension_b0

14 - SKIP_PROJS

指定要避免用于查询的表的投影。如果 SKIP_PROJS 不包括对查询有效的所有可用投影，则优化器会发出警告并忽略投影提示。

语法

FROM table-name /*+SKIP_PROJS( [[database.]schema.]projection[,...] )*/

参数

[database.]schema: 数据库和架构。默认架构为 public。如果指定一个数据库，它必须是当前数据库。
projection: 要跳过的投影。可以指定逗号分隔投影的列表。

示例

在此示例中，EXPLAIN 输出显示优化器使用了给定查询的投影 public.employee_dimension_b0：


QUERY PLAN DESCRIPTION:
------------------------------

 EXPLAIN SELECT employee_last_name, employee_first_name, employee_city, job_title FROM employee_dimension;

 Access Path:
 +-STORAGE ACCESS for employee_dimension [Cost: 59, Rows: 10K (NO STATISTICS)] (PATH ID: 1)
 |  Projection: public.employee_dimension_b0
 |  Materialize: employee_dimension.employee_first_name, employee_dimension.employee_last_name, employee_dimension.employee_city, employee_dimension.job_title
 |  Execute on: All Nodes

您可使用 SKIP_PROJS 提示避免使用此投射。如果有对此查询有效的其他投影，优化器将改用此投影：


QUERY PLAN DESCRIPTION:
------------------------------

EXPLAIN SELECT employee_last_name, employee_first_name, employee_city, job_title FROM employee_dimension /*+SKIP_PROJS('public.employee_dimension')*/;

 Access Path:
 +-STORAGE ACCESS for employee_dimension [Cost: 156, Rows: 10K (NO STATISTICS)] (PATH ID: 1)
 |  Projection: public.employee_dimension_super
 |  Materialize: employee_dimension.employee_first_name, employee_dimension.employee_last_name, employee_dimension.emplo
yee_city, employee_dimension.job_title
 |  Execute on: Query Initiator

15 - SKIP_STATISTICS

指示优化器生成仅包含由 ANALYZE_ROW_COUNT 收集的最少统计信息的查询计划。优化器会忽略由 ANALYZE_STATISTICS 和 ANALYZE_STATISTICS_PARTITION 使用和生成的其他统计信息。当用于对小型表执行查询时，此提示尤其有用，其中收集完整统计信息所需的时间量通常大于实际执行时间。

语法

SELECT /*+SKIP_STAT[ISTIC]S*/

EXPLAIN 输出

EXPLAIN 为包含 SKIP_STATISTICS（使用其缩写形式 SKIP_STATS）的查询返回以下输出：


=> EXPLAIN SELECT /*+ SKIP_STATS*/ customer_key, customer_name, customer_gender, customer_city||', '||customer_state, customer_age
    FROM customer_dimension WHERE customer_region = 'East' AND customer_age > 60;

 QUERY PLAN DESCRIPTION:
 ------------------------------

 EXPLAIN SELECT /*+ SKIP_STATS*/ customer_key, customer_name, customer_gender, customer_city||', '||customer_state,
 customer_age FROM customer_dimension WHERE customer_region = 'East' AND customer_age > 60;

 Access Path:
 +-STORAGE ACCESS for customer_dimension [Cost: 2K, Rows: 10K (STATISTICS SKIPPED)] (PATH ID: 1)
 |  Projection: public.customer_dimension_b0
 |  Materialize: public.customer_dimension.customer_age, public.customer_dimension.customer_key, public.customer_dimensi
on.customer_name, public.customer_dimension.customer_gender, public.customer_dimension.customer_city, public.customer_di
mension.customer_state
 |  Filter: (public.customer_dimension.customer_region = 'East')
 |  Filter: (public.customer_dimension.customer_age > 60)
 |  Execute on: All Nodes
...

16 - SYNTACTIC_JOIN

强制执行联接顺序并启用其他联接提示。

语法

SELECT /*+SYN[TACTIC]_JOIN*/

描述

为了实现最佳性能，优化器经常覆盖查询的指定联接顺序。通过包括 SYNTACTIC_JOIN 提示，可以确保优化器严格按规定强制执行查询的联接顺序。一个要求适用：联接语法必须符合 ANSI SQL-92 惯例。

SYNTACTIC_JOIN 提示必须紧跟在 SELECT 后面。如果带注释查询包含的另一个提示也必须跟在 SELECT 后面（例如 VERBATIM），则将这两个提示组合在一起。例如：

SELECT /*+ syntactic_join,verbatim*/

示例

在以下示例中，优化器为两个查询产生不同的计划，区别就在于包括或排除了 SYNTACTIC_JOIN 提示。

排除 SYNTACTIC_JOIN

EXPLAIN SELECT sales.store_key, stores.store_name, products.product_description, sales.sales_quantity, sales.sale_date
FROM (store.store_sales sales JOIN products ON sales.product_key=products.product_key)
JOIN store.store_dimension stores ON sales.store_key=stores.store_key
WHERE sales.sale_date='2014-12-01' order by sales.store_key, sales.sale_date;

 Access Path:
 +-SORT [Cost: 14K, Rows: 100K (NO STATISTICS)] (PATH ID: 1)
 |  Order: sales.store_key ASC, sales.sale_date ASC
 |  Execute on: All Nodes
 | +---> JOIN HASH [Cost: 11K, Rows: 100K (NO STATISTICS)] (PATH ID: 2) Outer (RESEGMENT)(LOCAL ROUND ROBIN) Inner (RESEGMENT)
 | |      Join Cond: (sales.product_key = products.product_key)
 | |      Materialize at Input: sales.store_key, sales.product_key, sales.sale_date, sales.sales_quantity
 | |      Execute on: All Nodes
 | | +-- Outer -> JOIN HASH [Cost: 1K, Rows: 100K (NO STATISTICS)] (PATH ID: 3)
 | | |      Join Cond: (sales.store_key = stores.store_key)
 | | |      Execute on: All Nodes
 | | | +-- Outer -> STORAGE ACCESS for sales [Cost: 1K, Rows: 100K (NO STATISTICS)] (PATH ID: 4)
 | | | |      Projection: store.store_sales_b0
 | | | |      Materialize: sales.store_key
 | | | |      Filter: (sales.sale_date = '2014-12-01'::date)
 | | | |      Execute on: All Nodes
 | | | |      Runtime Filter: (SIP1(HashJoin): sales.store_key)
 | | | +-- Inner -> STORAGE ACCESS for stores [Cost: 34, Rows: 250] (PATH ID: 5)
 | | | |      Projection: store.store_dimension_DBD_10_rep_VMartDesign_node0001
 | | | |      Materialize: stores.store_key, stores.store_name
 | | | |      Execute on: All Nodes
 | | +-- Inner -> STORAGE ACCESS for products [Cost: 3K, Rows: 60K (NO STATISTICS)] (PATH ID: 6)
 | | |      Projection: public.products_b0
 | | |      Materialize: products.product_key, products.product_description
 | | |      Execute on: All Nodes

包括 SYNTACTIC_JOIN

EXPLAIN SELECT /*+SYNTACTIC_JOIN*/ sales.store_key, stores.store_name, products.product_description, sales.sales_quantity, sales.sale_date
FROM (store.store_sales sales JOIN products ON sales.product_key=products.product_key)
JOIN store.store_dimension stores ON sales.store_key=stores.store_key
WHERE sales.sale_date='2014-12-01' order by sales.store_key, sales.sale_date;

 Access Path:
 +-SORT [Cost: 11K, Rows: 100K (NO STATISTICS)] (PATH ID: 1)
 |  Order: sales.store_key ASC, sales.sale_date ASC
 |  Execute on: All Nodes
 | +---> JOIN HASH [Cost: 8K, Rows: 100K (NO STATISTICS)] (PATH ID: 2)
 | |      Join Cond: (sales.store_key = stores.store_key)
 | |      Execute on: All Nodes
 | | +-- Outer -> JOIN HASH [Cost: 7K, Rows: 100K (NO STATISTICS)] (PATH ID: 3) Outer (BROADCAST)(LOCAL ROUND ROBIN)
 | | |      Join Cond: (sales.product_key = products.product_key)
 | | |      Execute on: All Nodes
 | | |      Runtime Filter: (SIP1(HashJoin): sales.store_key)
 | | | +-- Outer -> STORAGE ACCESS for sales [Cost: 2K, Rows: 100K (NO STATISTICS)] (PATH ID: 4)
 | | | |      Projection: store.store_sales_b0
 | | | |      Materialize: sales.sale_date, sales.store_key, sales.product_key, sales.sales_quantity
 | | | |      Filter: (sales.sale_date = '2014-12-01'::date)
 | | | |      Execute on: All Nodes
 | | | +-- Inner -> STORAGE ACCESS for products [Cost: 3K, Rows: 60K (NO STATISTICS)] (PATH ID: 5)
 | | | |      Projection: public.products_b0
 | | | |      Materialize: products.product_key, products.product_description
 | | | |      Execute on: All Nodes
 | | +-- Inner -> STORAGE ACCESS for stores [Cost: 34, Rows: 250] (PATH ID: 6)
 | | |      Projection: store.store_dimension_DBD_10_rep_VMartDesign_node0001
 | | |      Materialize: stores.store_key, stores.store_name
 | | |      Execute on: All Nodes

17 - UTYPE

指定如何组合 UNION ALL 输入。

语法

UNION ALL /*+UTYPE(union-type)*/

参数

union‑type

以下实参之一：

U：连接 UNION ALL 输入（默认）。
M：合并 UNION ALL 输入，排序顺序与源查询结果相同。此选项要求来自源查询的所有输入均采用相同的排序顺序；否则，Vertica 将发出警告并连接 UNION ALL 输入。

注意
优化器依靠查询或 DDL 来验证输入数据是否已排序，而不是依靠数据的实际运行时顺序。

要求

包含 UTYPE 提示的查询必须也包含 SYNTACTIC_JOIN 提示。否则，优化器会忽略 UTYPE 提示并抛出一条警告。

18 - VERBATIM

完全按编写强制执行带注释查询。

VERBATIM 指示优化器创建一个包含某带注释查询中所有提示的查询计划。而且，它指示优化器不将其自身的计划开发处理用于与这些提示相关的查询计划组件。

此提示的用法在 optimizer-generated 与 custom 定向查询之间有所不同，如下所述。

语法

SELECT /*+ VERBATIM*/

要求

VERBATIM 提示必须紧跟在 SELECT 后面。如果带注释查询包含的另一个提示也必须跟在 SELECT 后面（例如 SYNTACTIC_JOIN），则将这两个提示组合在一起。例如：

SELECT /*+ syntactic_join,verbatim*/

优化器生成的定向查询

在优化器为定向查询生成的带注释查询中，始终包含 VERBATIM 提示。例如，对于以下 CREATE DIRECTED QUERY OPTIMIZER 语句：


=> CREATE DIRECTED QUERY OPTIMIZER getStoreSales SELECT sales.store_key, stores.store_name, sales.product_description, sales.sales_quantity, sales.sale_date FROM store.storesales sales JOIN store.store_dimension stores ON sales.store_key=stores.store_key WHERE sales.sale_date='2014-12-01' /*+IGNORECONST(1)*/ AND stores.store_name='Store1' /*+IGNORECONST(2)*/ ORDER BY sales.store_key, sales.sale_date;
CREATE DIRECTED QUERY

优化器将生成包含 VERBATIM 提示的带注释查询：

=> SELECT query_name, annotated_query FROM V_CATALOG.DIRECTED_QUERIES WHERE query_name = 'getStoreSales';
-[ RECORD 1 ]---+------
query_name      | getStoreSales
annotated_query | SELECT /*+ syntactic_join,verbatim*/ sales.store_key AS store_key, stores.store_name AS store_name, sales.product_description AS product_description, sales.sales_quantity AS sales_quantity, sales.sale_date AS sale_date
FROM (store.storeSales AS sales/*+projs('store.storeSales')*/ JOIN /*+Distrib(L,L),JType(H)*/ store.store_dimension AS stores/*+projs('store.store_dimension_DBD_10_rep_VMartDesign')*/  ON (sales.store_key = stores.store_key))
WHERE (sales.sale_date = '2014-12-01'::date /*+IgnoreConst(1)*/) AND (stores.store_name = 'Store1'::varchar(6) /*+IgnoreConst(2)*/)
ORDER BY 1 ASC, 5 ASC

当优化器使用此定向查询时，将生成一个查询计划，该查询计划与其生成此定向查询时所使用的查询计划相等同：

=> ACTIVATE DIRECTED QUERY getStoreSales;
ACTIVATE DIRECTED QUERY

=> EXPLAIN SELECT sales.store_key, stores.store_name, sales.product_description, sales.sales_quantity, sales.sale_date FROM store.storesales sales JOIN store.store_dimension stores ON sales.store_key=stores.store_key WHERE sales.sale_date='2014-12-04' AND stores.store_name='Store14' ORDER BY sales.store_key, sales.sale_date;

 QUERY PLAN DESCRIPTION:
 ------------------------------

 EXPLAIN SELECT sales.store_key, stores.store_name, sales.product_description, sales.sales_quantity, sales.sale_date FROM store.storesales sales JOIN store.store_dimension stores ON sales.store_key=stores.store_key WHERE sales.sale_date='2014-12-04' AND stores.store_name='Store14' ORDER BY sales.store_key, sales.sale_date;

 The following active directed query(query name: getStoreSales) is being executed:
 SELECT /*+syntactic_join,verbatim*/ sales.store_key, stores.store_name, sales.product_description, sales.sales_quantity, sales.sale_date
FROM (store.storeSales sales/*+projs('store.storeSales')*/ JOIN /*+Distrib('L', 'L'), JType('H')*/store.store_dimension stores
/*+projs('store.store_dimension_DBD_10_rep_VMartDesign')*/ ON ((sales.store_key = stores.store_key))) WHERE ((sales.sale_date = '2014-12-04'::date)
AND (stores.store_name = 'Store14'::varchar(7))) ORDER BY sales.store_key, sales.sale_date

 Access Path:
 +-JOIN HASH [Cost: 463, Rows: 622 (NO STATISTICS)] (PATH ID: 2)
 |  Join Cond: (sales.store_key = stores.store_key)
 |  Materialize at Output: sales.sale_date, sales.sales_quantity, sales.product_description
 |  Execute on: All Nodes
 | +-- Outer -> STORAGE ACCESS for sales [Cost: 150, Rows: 155K (NO STATISTICS)] (PATH ID: 3)
 | |      Projection: store.storeSales_b0
 | |      Materialize: sales.store_key
 | |      Filter: (sales.sale_date = '2014-12-04'::date)
 | |      Execute on: All Nodes
 | |      Runtime Filter: (SIP1(HashJoin): sales.store_key)
 | +-- Inner -> STORAGE ACCESS for stores [Cost: 35, Rows: 2] (PATH ID: 4)
 | |      Projection: store.store_dimension_DBD_10_rep_VMartDesign_node0001
 | |      Materialize: stores.store_name, stores.store_key
 | |      Filter: (stores.store_name = 'Store14')
 | |      Execute on: All Nodes

自定义定向查询

只有当您为定向查询编写的带注释查询中显式包含 VERBATIM 提示时，自定义定向查询才会包含该提示。当优化器使用该定向查询时，会遵循 VERBATIM 提示，相应地创建查询计划。

如果您在创建自定义定向查询时忽略了 VERBATIM 提示，则不会将该提示与带注释查询一起存储起来。当优化器使用该定向查询时，会将其自身的计划开发处理应用于带注释查询，然后再生成查询计划。相比于此查询计划，若优化器针对创建定向查询时所使用的 Vertica 版本生成查询计划，则后者可能与之不等同。