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 <col_name>)
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 <col_name>)
.
Tipos de dados suportados¶
O serviço de otimização de pesquisa atualmente oferece suporte aos seguintes tipos de dados:
Tipos de dados para números de ponto fixo (por exemplo, INTEGER e NUMERIC)
Tipos de dados de cadeia de caracteres e binários (por exemplo, VARCHAR e BINARY)
Tipos de dados de data e hora (por exemplo, DATE, TIME e TIMESTAMP)
Tipos de dados semiestruturados (por exemplo, VARIANT, OBJECT e ARRAY)
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
ouSUBSTRING
, 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');
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);
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';
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';
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';
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;
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.