vertica-distinct，projection的segment by，order by

1，计算distinct聚合比其他聚合更消耗资源，查询中distinct聚合能够替换成其他聚合往往效率更高

注意：

多个distinct聚合语句不能非常直接的重写，而且没有办法让Projection避免进行GROUP BY HASH和数据重新分段，也就是说此事将会有hash by重新计算，然后排序，各节点数据重新分布（注意这里的分布都是不落地的），然后在运算，这样是极其不合理的。为了保证正常运行和提升性能需要保证足够的内存，因此处于性能考虑尽可能避免同一个语句中出现多个DISTINCT聚合，可以用group by代替的。

2，Vertica使用了两种算法的join方式，分别是 hash join和merge join。

如下第一个查询比第二个查询性能优化，因为第二个需要更多的计算

SELECT * FROM T JOIN X WHERE T.a - T.b = X.x1; 

VS 

SELECT * FROM T JOIN X WHERE T.a = X.x1 + T.b

使得join效率得到优化，要检查是否总是选择了大表作外层表，小表作内层表。为了提升多表关联效率，创建projection让其能够在关联键上相等的分段，，这种projection叫做ISPS，ISPS允许关联查询只在每个本地节点上查询数据，不需要跨节点移动数据。

判断projection是否在查询时的关联键上想等分段时，使用explain，若输出包含RESEGMENT或者  BROADCAST，则就不是想等分段。

create table t1(id int,x1 int,y1 int) segmented by hash(id) all nodes;

create table t2(id int,x2 int,y2 int) segmented by hash(id) all nodes;

explain SELECT * FROM t1 JOIN t2 ON t1.id = t2.id AND t1.x1 = t2.x2;

可以看到这个sql数据没有进行重新分布就计算，说明是想等关联分段ISPS

explain SELECT * FROM t1 JOIN t2 ON t1.x1 = t2.x2;

这里进行了数据重新分布计算，不是相等分段

3，order by对性能影响

我们在查询表的时候可以多看看标的ddl，其设计的排序方式对性能影响很大

然后尽量使得查询语句和表的相关projection的order by 子句相同，这样性能更好

CREATE TABLE sortopt ( 

a INT NOT NULL, 

b INT NOT NULL,

 c INT, d INT ); 

CREATE PROJECTION sortopt_p ( 

a_proj, 

b_proj,

 c_proj, 

d_proj )

 AS SELECT * FROM sortopt 

ORDER BY a,b,c 

UNSEGMENTED ALL NODES; 

INSERT INTO sortopt VALUES(5,2,13,84); 

INSERT INTO sortopt VALUES(14,22,8,115);

INSERT INTO sortopt VALUES(79,9,401,33);

#查询包含以下order by子句可以不必重新排序ORDER BY a 、ORDER BY a, b 、ORDER BY a, b, c 但是下面查询需要重新排序，因为创建Projection时不能指定排序方式，物理存储上只能是asc方式 SELECT * FROM sortopt ORDER BY a DESC b, c;