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 <col_name>) 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 <col_name>).

Tipos de dados suportados

O serviço de otimização de pesquisa atualmente oferece suporte aos seguintes tipos de dados:

As consultas que envolvem outros valores de outros tipos de dados (por exemplo, FLOAT ou GEOMETRY) não se beneficiam.

Tipos de predicados compatíveis

A otimização de pesquisa pode melhorar o desempenho de consultas usando estes tipos de predicados:

Suporte a agrupamento

A otimização de pesquisa pode melhorar o desempenho das consultas em colunas definidas com uma cláusula COLLATE, dependendo do método de pesquisa:

  • Quando a otimização de pesquisa está ativada em uma coluna usando o método de pesquisa EQUALITY, qualquer especificação de agrupamento é compatível.

  • Quando a otimização de pesquisa é ativada em uma coluna usando o método de pesquisa FULL_TEXT ou SUBSTRING, as especificações de agrupamento 'utf8' ou 'bin' são compatíveis.

Para obter mais informações sobre métodos de pesquisa, consulte ALTER TABLE … ADD SEARCH OPTIMIZATION.

A otimização de pesquisa não é compatível com predicados que alteram a especificação de agrupamento de uma coluna usando a função COLLATE.

Por exemplo, crie uma tabela com colunas que tenham especificações de agrupamento e insira uma linha:

CREATE OR REPLACE TABLE search_optimization_collation_demo (
  en_ci_col VARCHAR COLLATE 'en-ci',
  utf_8_col VARCHAR COLLATE 'utf8');

INSERT INTO search_optimization_collation_demo VALUES (
  'test_collation_1',
  'test_collation_2');
Copy

Ative a otimização de pesquisa para predicados de igualdade em ambas as colunas da tabela:

ALTER TABLE search_optimization_collation_demo
  ADD SEARCH OPTIMIZATION ON EQUALITY(en_ci_col, utf_8_col);
Copy

A consulta a seguir pode se beneficiar da otimização de pesquisa:

SELECT *
  FROM search_optimization_collation_demo
  WHERE utf_8_col = 'test_collation_2';
Copy

A consulta a seguir não pode se beneficiar da otimização de pesquisa porque altera a especificação de agrupamento da coluna utf_8_col usando a função COLLATE:

SELECT *
  FROM search_optimization_collation_demo
  WHERE utf_8_col COLLATE 'de-ci' = 'test_collation_2';
Copy

A consulta a seguir também não pode se beneficiar da otimização de pesquisa. Com base nas regras de agrupamento de precedência, a consulta aplica a especificação de agrupamento 'de-ci' à coluna utf_8_col usando a função COLLATE.

SELECT *
  FROM search_optimization_collation_demo
  WHERE utf_8_col = 'test_collation_2' COLLATE 'de-ci';
Copy

Suporte a tabelas Apache Iceberg™

A otimização de pesquisa pode melhorar o desempenho das consultas nas tabelas Apache Iceberg™. Para obter informações sobre como configurar a otimização de pesquisa para tabelas Iceberg, consulte ALTER ICEBERG TABLE.

As seguintes limitações se aplicam ao suporte de otimização de pesquisa para tabelas Iceberg:

  • A otimização de pesquisa não pode ser adicionada a colunas com tipos de dados não compatíveis com as tabelas Iceberg, que incluem os tipos de dados semiestruturados e geoespaciais. Para obter mais informações, consulte Tipos de dados para tabelas Apache Iceberg™.

  • O serviço de otimização de pesquisa não oferece suporte a colunas com tipos de dados estruturados.

  • Se os arquivos do Apache Parquet™ forem muito grandes (por exemplo, centenas de megabytes compactados), as consultas poderão não se beneficiar totalmente do serviço de otimização de pesquisa em alguns cenários.

Outras limitações que se aplicam à otimização de pesquisa para tabelas Snowflake também se aplicam às tabelas Iceberg. Para obter mais informações, consulte Consultas que não se beneficiam da otimização de pesquisa.

Melhorias potenciais para as 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.

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.

  • Exibições materializadas.

  • 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.