通过列的不存在/非典型值进行过滤会导致性能缓慢。

Question

FAST (<0.1s)

SELECT 1
FROM   sample
JOIN   unit ON sample.unit_key = unit.key
WHERE  sample.sample_id = 'http://example.com/foo';

+-JOIN HASH [Cost: 2K, Rows: 37] (PATH ID: 1)
|  Join Cond: (sample.UNIT_KEY = unit.KEY)
| +-- Outer -> STORAGE ACCESS for unit [Cost: 987, Rows: 3M] (PATH ID: 2)
| |      Projection: OLAPTEST_PRIVATE.UNIT_super
| |      Materialize: unit.KEY
| |      Runtime Filter: (SIP1(HashJoin): unit.KEY)
| +-- Inner -> STORAGE ACCESS for sample [Cost: 92, Rows: 37] (PATH ID: 3)
| |      Projection: OLAPTEST_PRIVATE.SAMPLE_super
| |      Materialize: sample.UNIT_KEY
| |      Filter: (sample.SAMPLE_ID = 'http://example.com/foo')

慢 (> 2s)

SELECT 1
FROM   sample
JOIN   unit ON sample.unit_key = unit.key
WHERE  sample.sample_id = 'foo';

+-JOIN HASH [Cost: 5K, Rows: 1 (PREDICATE VALUE OUT-OF-RANGE)] (PATH ID: 1)
|  Join Cond: (sample.UNIT_KEY = unit.KEY)
| +-- Outer -> STORAGE ACCESS for sample [Cost: 90, Rows: 1 (PREDICATE VALUE OUT-OF-RANGE)] (PATH ID: 2)
| |      Projection: OLAPTEST_PRIVATE.SAMPLE_super
| |      Materialize: sample.UNIT_KEY
| |      Filter: (sample.SAMPLE_ID = 'foo')
| |      Runtime Filter: (SIP1(HashJoin): sample.UNIT_KEY)
| +-- Inner -> STORAGE ACCESS for unit [Cost: 987, Rows: 3M] (PATH ID: 3)
| |      Projection: OLAPTEST_PRIVATE.UNIT_super
| |      Materialize: unit.KEY

• 由'foo‘(列中无存在值) -> http://example.com/...(列中无存在值) -> http://example.com/...慢
• 过滤器按'http://example.com/foo’(列中无存在值) -> fast

H 115过滤器(列中现有值) -> fastH 217过滤

有了联接，查询就快了。

列sample_id中的所有值都以“http://example.com/.”开头

我分析了所有表格的统计数据。

• SAMPLE_ID VARCHAR(1000) NOT NULL (AUTO encoding).没有唯一的约束，外键等。
• SAMPLE= 10k行
• UNIT = 30M+ rows

对于不存在的值，sample_id列会有什么原因导致过滤速度这么慢？由表中其他列(具有更多不同值但几乎没有不同值)进行的筛选都表现良好。

对另一个表(例如单元)执行类似的查询，该表中也有值为http的列，但没有类似的性能效果。

我能做什么?如果用户给出一个不存在的值，我不希望应用程序慢下来.

我们仍然在Vertica 7上，希望很快用更新的版本更新到新的集群(那时我们还可以为表创建更好的预测)。

Answer 1

因为SAMPLE表太小了，所以应该是UNSEGMENTED。将分段的超投影替换为未分割的投影--这只是这样一个小表的最佳实践。另外，将SAMPLE表作为UNSEGMENTED将消除连接期间的全局重新分割。

另外，尝试将sample_id作为投影的ORDER BY子句中的第一列。这将不会创建合并，但它将优化WHERE子句筛选器。

如果这有帮助的话请告诉我。如果没有，请包括整个解释计划与新的投影(包括图形)。