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;
      
      Copy
    • 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;
      
      Copy

    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 que COUNT(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;
    
    Copy

    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';
    
    Copy

    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'
Copy

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.