Identificação de consultas que podem se beneficiar da otimização de pesquisa¶
A otimização de pesquisa pode melhorar o desempenho de muitas consultas. Este tópico descreve as características dos tipos de consultas em que a otimização de pesquisa mais ajuda e, inversamente, os tipos de consultas que não se beneficiam.
Características gerais da consulta¶
A otimização de pesquisa funciona melhor para melhorar o desempenho de consultas com as seguintes características:
A consulta envolve uma coluna ou colunas diferentes da chave primária do cluster.
A consulta normalmente é executada por alguns segundos ou mais (antes de aplicar a otimização de pesquisa). Na maioria dos casos, a otimização de pesquisa não melhorará substancialmente o desempenho de uma consulta que tem um tempo de execução de fração de segundo.
Pelo menos uma das colunas acessadas pela operação de filtro de consulta tem na ordem de 100.000 valores distintos ou mais.
Para determinar o número de valores distintos, você pode usar um dos seguintes
Use
APPROX_COUNT_DISTINCT
para obter o número aproximado de valores distintos:select approx_count_distinct(column1) from table1;
Use
COUNT(DISTINCT <nome_da_coluna>)
para obter o número real de valores distintos:select count(distinct c1), count (distinct c2) from test_table;
Como você só precisa de uma aproximação do número de valores distintos, considere o uso de
APPROX_COUNT_DISTINCT
, que geralmente é mais rápido e mais barato do queCOUNT(DISTINCT <nome_da_coluna>)
.
Tipos de dados suportados¶
O serviço de otimização de pesquisa atualmente oferece suporte aos seguintes tipos de dados:
Números de ponto fixo (por exemplo, INTEGER, NUMERIC).
DATE, TIME e TIMESTAMP.
VARCHAR.
BINARY.
VARIANT, OBJECT e ARRAY.
GEOGRAPHY.
Consultas que envolvem outros tipos de valores (ou seja, FLOAT, GEOMETRY) não são beneficiadas.
Tipos de predicados compatíveis¶
A otimização de pesquisa pode melhorar o desempenho de consultas usando estes tipos de predicados:
Outras melhorias potenciais¶
A otimização de pesquisa também pode melhorar o desempenho das exibições e das consultas que usam JOIN.
Exibições¶
O serviço de otimização de pesquisa pode melhorar indiretamente o desempenho das exibições (incluindo exibições seguras). Se uma tabela base para uma exibição tiver a otimização de pesquisa ativada e a consulta usar um predicado seletivo para aquela tabela, o serviço de otimização de pesquisa pode melhorar o desempenho ao filtrar as linhas. Consulte Tipos de predicados compatíveis.
Nem todas as tabelas na exibição precisam ter a otimização de pesquisa ativada. A otimização de pesquisa é realizada em cada tabela independentemente.
Junções¶
O serviço de otimização de pesquisa não melhora diretamente o desempenho das junções. No entanto, ele pode melhorar o desempenho da filtragem das linhas de qualquer uma das tabelas antes da junção. Essa melhoria pode ocorrer quando a tabela tem a otimização de pesquisa habilitada e o predicado é seletivo, conforme discutido em Tipos de predicados compatíveis.
Ambas as tabelas não precisam ter a otimização de pesquisa habilitada. A decisão de utilizar a otimização de pesquisa é tomada para cada tabela independentemente.
Consultas que não se beneficiam da otimização de pesquisa¶
Atualmente, o serviço de otimização de pesquisa não oferece suporte a tipos de dados de ponto flutuante, GEOMETRY ou outros tipos de dados não discutidos ainda. O Snowflake pode acrescentar suporte para mais tipos de dados no futuro.
Além disso, o serviço de otimização de pesquisa não suporta o seguinte:
Tabelas externas.
Tabelas dinâmicas.
Exibições materializadas.
Colunas definidas com uma cláusula COLLATE.
Concatenação de colunas.
Expressões analíticas.
Conversões em colunas de tabela (exceto para números de ponto fixo convertidos em cadeias de caracteres).
Embora a otimização de pesquisa suporte predicados com conversões implícitas e explícitas sobre valores constantes, ela não suporta predicados que convertam valores na coluna da tabela real (exceto para conversões de INTEGER e NUMBER em VARCHAR).
Por exemplo, os seguintes predicados têm suporte porque utilizam conversões implícitas e explícitas de valores constantes (e não valores na coluna da tabela):
-- Supported predicate -- (where the string '2020-01-01' is implicitly cast to a date) WHERE timestamp1 = '2020-01-01'; -- Supported predicate -- (where the string '2020-01-01' is explicitly cast to a date) WHERE timestamp1 = '2020-01-01'::date;
O seguinte predicado não tem suporte porque utiliza uma conversão dos valores na coluna da tabela:
-- Unsupported predicate -- (where values in a VARCHAR column are cast to DATE) WHERE to_date(varchar_column) = '2020-01-01';
O serviço de otimização de pesquisa considera os valores originais da coluna, não os valores após a conversão. Como resultado, o serviço de otimização de pesquisa não é utilizado para consultas com esses predicados.
Como observado, a exceção a esta regra é a de converter valores NUMBER ou INTEGER em valores VARCHAR na coluna da tabela. O serviço de otimização de pesquisa suporta este tipo de predicado:
-- Supported predicate -- (where values in a numeric column are cast to a string) WHERE cast(numeric_column as varchar) = '2'
A otimização de pesquisa não melhora o desempenho das consultas que utilizam Time Travel porque a otimização de pesquisa funciona somente com dados ativos.