Monitoramento da atividade de consulta com o Histórico de consultas¶

Privilégios necessários para visualizar o histórico de consultas¶

Você sempre pode visualizar o histórico das consultas executadas.

Para visualizar o histórico de outras consultas, sua função ativa afeta o que mais você pode ver em Query History:

• Se sua função ativa for a função ACCOUNTADMIN, você poderá visualizar todo o histórico de consultas da conta.

• Se sua função ativa tiver o privilégio MONITOR ou OPERATE concedido em um warehouse, você poderá visualizar consultas executadas por outros usuários que usam esse warehouse.

• Se sua função ativa receber a função de banco de dados GOVERNANCE_VIEWER para o banco de dados SNOWFLAKE, você poderá visualizar o histórico de consultas de todos os usuários em sua conta. Consulte Funções de banco de dados SNOWFLAKE.

• Se a função de banco de dados READER_USAGE_VIEWER for concedida à sua função ativa para o banco de dados SNOWFLAKE, você poderá visualizar o histórico de consultas de todos os usuários nas contas de leitor associadas à sua conta. Consulte Funções de banco de dados SNOWFLAKE.

Considerações sobre o uso do histórico de consultas¶

Ao analisar o Query History da sua conta, considere o seguinte:

• Os detalhes das consultas executadas há mais de sete dias não incluem as informações de User devido à política de retenção de dados das sessões. Você pode usar o filtro de usuário para recuperar consultas executadas por usuários individuais. Consulte Filtro do histórico de consultas.

• Para consultas que falharam devido a erros de sintaxe ou de análise, você verá <redigido> em vez da instrução SQL que foi executada. Se você receber uma função com privilégios apropriados, poderá definir o parâmetro ENABLE_UNREDACTED_QUERY_SYNTAX_ERROR para visualizar o texto completo da consulta.

• Os filtros e as colunas Started e End Time usam seu fuso horário atual. Você não pode alterar essa configuração. Definir o parâmetro TIMEZONE para a sessão não altera o fuso horário usado.

Filtro do histórico de consultas¶

É possível filtrar a lista Histórico de consultas da seguinte forma:

• Status da consulta, por exemplo, para identificar consultas de longa duração, consultas com falha e consultas em fila.

• Usuário que realizou a consulta, incluindo:

  • All, para ver todos os usuários aos quais você tem acesso para visualizar o histórico de consultas.

  • O usuário que você usou para entrar (padrão)

  • Usuários individuais do Snowflake em sua conta, se sua função puder visualizar o histórico de consultas de outros usuários.

• Período durante o qual a consulta foi executada, até 14 dias.

• Outros filtros, incluindo os seguintes:

  • SQL Text, por exemplo, para visualizar consultas que usam instruções específicas, como GROUP BY.

  • Query ID, para visualizar detalhes de uma consulta específica.

  • Warehouse, para visualizar consultas que foram executadas usando um warehouse específico.

  • Statement Type, para visualizar consultas que usaram um tipo específico de instrução, como DELETE, UPDATE, INSERT ou SELECT.

  • Duration, por exemplo, para identificar consultas especialmente de longa duração.

  • Session ID, para visualizar consultas executadas durante uma sessão específica do Snowflake.

  • Query Tag, para visualizar consultas com uma tag de consulta específica definida por meio do parâmetro de sessão QUERY_TAG.

  • Parameterized Query Hash, para exibir as consultas agrupadas de acordo com o ID de hash de consulta parametrizada especificado no filtro. Para obter mais informações, consulte Uso do hash da consulta parametrizada (query_parameterized_hash).

  • Client generated statements, para visualizar consultas internas executadas por um cliente, driver ou biblioteca, incluindo a interface da web. Por exemplo, sempre que um usuário navega para a página Warehouses no Snowsight, o Snowflake executa uma instrução SHOW WAREHOUSES em segundo plano. Essa instrução ficaria visível quando este filtro estivesse habilitado. Sua conta não é cobrada por instruções geradas pelo cliente.

  • Queries executed by user tasks, para visualizar instruções SQL executadas ou procedimentos armazenados chamados pelas tarefas do usuário.

  • Show replication refresh history, para visualizar consultas usadas para executar tarefas de atualização de replicação em regiões e contas remotas.

Se quiser ver resultados quase em tempo real, ative Auto Refresh. Quando Auto Refresh está ativado, a tabela é atualizada a cada dez segundos.

Você pode ver as seguintes colunas na tabela Queries por padrão:

• SQL Text, o texto da instrução executada (sempre mostrado).

• Query ID, a ID da consulta (sempre mostrado).

• Status, o status da instrução executada (sempre mostrado).

• User, para ver o nome de usuário que executou uma instrução.

• Warehouse, para ver o warehouse usado para executar uma instrução.

• Duration, para ver quanto tempo levou para executar uma instrução.

• Started, para ver a hora em que uma instrução começou a ser executada.

Se você tiver mais resultados, não poderá classificar a tabela. Se você selecionar Load More no topo da lista após classificar a tabela, os novos resultados serão anexados ao final dos dados e a ordem de classificação não será mais aplicada.

Para visualizar informações mais específicas, você pode selecionar Columns para adicionar ou remover colunas da tabela, como:

• All para exibir todas as colunas.

• User para exibir o usuário que executou a instrução.

• Warehouse para exibir o nome do warehouse usado para executar a instrução.

• Warehouse Size para exibir o tamanho do warehouse usado para executar a instrução.

• Duration para exibir o tempo necessário para a execução da instrução.

• Started para exibir a hora de início da instrução.

• End Time para exibir a hora de término da instrução.

• Session ID para exibir a ID da sessão que executou a instrução.

• Client Driver para exibir o nome e a versão do cliente, driver ou biblioteca usada para executar a instrução. As instruções executadas em Snowsight mostram Go 1.1.5.

• Bytes Scanned para exibir o número de bytes verificados durante o processamento da consulta.

• Rows para exibir o número de linhas retornadas por uma instrução.

• Query Tag para exibir a tag de consulta definida para uma consulta.

• Parameterized Query Hash para exibir consultas agrupadas de acordo com o ID de hash de consulta parametrizada especificado no filtro. Para obter mais informações, consulte Uso do hash da consulta parametrizada (query_parameterized_hash).

• Incident para exibir detalhes de instruções com status de execução de incidente, usadas para fins de solução de problemas ou depuração.

Para visualizar detalhes adicionais sobre uma consulta, selecione uma consulta na tabela para abrir o Query Details.

Como usar o Histórico de consultas agrupadas¶

Para acessar Grouped Query History no Snowsight, faça o seguinte:

1. Faça login na Snowsight.

2. Selecione Monitoring » Query History » Grouped Queries. A página mostra as consultas agrupadas por seu ID de hash de consulta parametrizada comum.

   Nota

   As consultas individuais não aparecem imediatamente na lista Grouped Queries. A latência para atualizar a lista a partir dos registros na exibição AGGREGATE_QUERY_HISTORY pode ser de até 180 minutos (3 horas), mas a lista geralmente é preenchida muito mais rapidamente.

3. Selecione qualquer consulta agrupada para ver as estatísticas de desempenho desse hash de consulta parametrizado. O Snowsight exibe o número total de consultas executadas, o número de consultas que falharam, a latência (p50, p90, p99) e as execuções por minuto. A seção inferior da página mostra alguns exemplos de consultas individuais executadas como parte desse hash; é possível selecionar cada consulta para ver seus detalhes específicos.

   Por exemplo, durante o último dia, cerca de 35 milhões de consultas foram executadas nesse grupo, com uma duração total de 196 horas e um tempo total de fila de 87 ms:

   

   Na parte inferior da página, é possível classificar a lista de consultas por status, duração e outras métricas.

4. Selecione Monitoring » Query History » Individual Queries para ver as consultas individuais.

   Essa exibição não reflete todas as consultas executadas pelas cargas de trabalho do Unistore, dado o grande volume de consultas que podem ser criadas em tabelas híbridas. Para obter mais informações sobre este comportamento, consulte Histórico de consultas para tabelas híbridas.

   A Snowflake recomenda que todos os usuários com cargas de trabalho do Unistore comecem pela exibição Grouped Queries.

Embora não seja possível filtrar a lista Grouped Queries, você mesmo pode executar consultas agregadas que retornam resultados filtrados.

Privilégios necessários para visualizar o Histórico de consultas agrupadas¶

Os usuários sempre podem visualizar o histórico das consultas que executaram. A função ativa de um usuário afeta quais outras consultas são visíveis. É possível visualizar Grouped Queries e Individual Queries se uma das opções a seguir for verdadeira:

• Sua função ativa é ACCOUNTADMIN.

• Sua função ativa recebeu IMPORTED PRIVILEGES no banco de dados SNOWFLAKE (consulte Habilitando outras funções para usar esquemas no banco de dados SNOWFLAKE).

• Você tem a função de banco de dados GOVERNANCE_VIEWER.

Se você não tiver nenhuma dessas funções ou privilégios, só poderá ver Individual Queries. Para obter mais informações sobre privilégios de acesso, consulte Monitoramento da atividade de consulta com o Histórico de consultas.

Consulta de dados do perfil censurados de um Snowflake Native App¶

O Snowflake Native App Framework censura as informações do perfil de consulta nos seguintes contextos:

• Consultas executadas quando o aplicativo é instalado ou atualizado.

• Consultas originadas de um procedimento armazenado de propriedade do aplicativo.

• Consultas contendo uma exibição ou função não segura de propriedade do aplicativo.

Para cada um desses tipos de consultas, Snowsight recolhe os dados do perfil de consulta em um único nó vazio em vez de exibir a árvore completa do perfil de consulta.

Revisão dos detalhes da consulta¶

Para revisar os detalhes de uma consulta específica e visualizar os resultados de uma consulta bem-sucedida, abra o Query Details de uma consulta.

Você pode revisar Details para obter informações sobre a execução da consulta, incluindo:

• O status da consulta.

• Quando a consulta foi iniciada, no fuso horário local do usuário.

• Quando a consulta terminou, no fuso horário local do usuário.

• O tamanho do warehouse usado para executar a consulta.

• A duração da consulta.

• A ID da consulta.

• A tag de consulta da consulta, se existir.

• O status do driver. Para obter mais detalhes, consulte Exibição das versões do cliente Snowflake.

• O nome e a versão do cliente, driver ou biblioteca usada para enviar a consulta. Por exemplo, Go 1.1.5 para consultas executadas usando Snowsight.

• A ID da sessão.

Você pode ver o warehouse usado para executar a consulta e o usuário que executou a consulta listados acima da guia Query Details.

Revise a seção SQL Text para obter o texto real da consulta. Você pode passar o mouse sobre o texto SQL para abrir a instrução em uma planilha ou copiar a instrução. Se a consulta falhar, você poderá revisar os detalhes do erro.

A seção Results mostra os resultados da consulta. Você só pode visualizar as primeiras 10.000 linhas de resultados, e somente o usuário que executou a consulta pode visualizar os resultados. Selecione Export Results para exportar o conjunto completo de resultados como um arquivo formatado em CSV.

Solução de problemas pois os detalhes da consulta podem estar indisponíveis¶

Se uma consulta não tiver detalhes de consulta, algumas causas possíveis incluem o seguinte:

• A consulta ainda está em andamento. Quando a execução da consulta terminar, você poderá visualizar os detalhes e o perfil da consulta.

• Sua função não tem privilégios para visualizar os detalhes da consulta.

• A consulta foi executada há mais de 14 dias e os detalhes e o perfil da consulta não estão mais disponíveis.

• A consulta falhou ao ser executada e, portanto, não possui perfil de consulta.

• Embora a plataforma Snowflake tenha sido projetada para preservar os detalhes do trabalho, a profundidade dos detalhes da consulta do trabalho e as métricas do perfil da consulta são feitas com base no melhor esforço e não são garantidas para todas as consultas.

Revisão do perfil de consulta¶

A guia Query Profile permite explorar o plano de execução da consulta e compreender detalhes granulares sobre cada etapa de execução.

O perfil da consulta é uma ferramenta poderosa para compreender a mecânica das consultas. Pode ser usado sempre que você precisar saber mais sobre o desempenho ou comportamento de uma determinada consulta. É projetado para ajudar a detectar erros típicos em expressões de consulta SQL para identificar possíveis gargalos de desempenho e oportunidades de melhoria.

Esta seção fornece uma breve visão geral de como navegar e usar o perfil de consulta.

• Plano de execução da consulta

• Nó do operador

• Navegação no perfil de consulta

• Painéis informativos

Interface	Descrição
Plano de execução da consulta	O plano de execução da consulta aparece no centro do perfil da consulta. O plano de execução da consulta é composto por nós de operador, que representam operadores de conjunto de linhas. As setas entre os nós do operador indicam os conjuntos de linhas que fluem de um operador para outro.
Nó do operador	Cada nó de operador inclui o seguinte: O tipo de operador e o número da ID. O tempo usado para executar este operador, representado como uma porcentagem da duração da consulta. Uma visualização dos detalhes do operador. Por exemplo, o nome de uma tabela ou de uma lista de expressões.
Navegação no perfil de consulta	No canto superior esquerdo do perfil de consulta, use os botões para: Passar pelas etapas de execução. Ajustar o plano de execução da consulta na janela. Ampliar e reduzir o plano de execução da consulta. Nota As etapas só aparecem se a consulta foi executada em etapas.
Painéis informativos	O perfil de consulta fornece vários painéis de informação. Os painéis aparecem no plano de execução da consulta. Os painéis que aparecem dependem do foco do plano de execução da consulta. O perfil de consulta inclui os seguintes painéis de informação: Profile Overview Statistics Most Expensive Nodes Attributes Para saber mais sobre as informações fornecidas pelos painéis, consulte Referência do perfil de consulta.

Consulta de dados do histórico censurados de um Snowflake Native App¶

Para consultas relacionadas a Snowflake Native App, os campos query_text e error_message são censurados do histórico de consultas nos seguintes contextos:

• As consultas são executadas quando o aplicativo é instalado ou atualizado.

• Consultas originadas de um trabalho filho de um procedimento armazenado de propriedade do aplicativo.

Em cada uma dessas situações, a célula do histórico de consultas em Snowsight aparece em branco.

Visão geral do perfil¶

O painel fornece informações sobre quais tarefas de processamento consumiram tempo de consulta. O tempo de execução fornece informações sobre “onde o tempo foi gasto” durante o processamento de uma consulta. O tempo gasto pode ser dividido nas seguintes categorias:

• Processing — tempo gasto no processamento de dados pela CPU.

• Local Disk IO — hora em que o processamento foi bloqueado pelo acesso a disco local.

• Remote Disk IO — hora em que o processamento foi bloqueado pelo acesso a disco remoto.

• Network Communication — tempo em que o processamento aguardava a transferência dos dados da rede.

• Synchronization — diversas atividades de sincronização entre os processos participantes.

• Initialization — tempo gasto na preparação do processamento da consulta.

• Hybrid Table Requests Throttling — tempo gasto limitando solicitações de leitura e gravação de dados armazenados em tabelas híbridas.

Estatísticas¶

Uma das principais fontes de informações fornecidas no painel de detalhes são as diversas estatísticas, agrupadas nas seções seguintes:

• IO — informações sobre as operações de entrada-saída realizadas durante a consulta:

  • Scan progress — a porcentagem de dados verificados para uma determinada tabela até o momento.

  • Bytes scanned — o número de bytes verificados até o momento.

  • Percentage scanned from cache — a porcentagem de dados verificados a partir do cache do disco local.

  • Bytes written — bytes gravados (por exemplo, ao carregar em uma tabela).

  • Bytes written to result — bytes gravados no objeto de resultado. Por exemplo, select * from . . . produziria um conjunto de resultados em formato tabular representando cada campo na seleção. Em geral, o objeto de resultado representa tudo o que é produzido como resultado da consulta, e Bytes gravados no resultado representa o tamanho do resultado retornado.

  • Bytes read from result — bytes lidos do objeto de resultado.

  • External bytes scanned — bytes lidos a partir de um objeto externo, por exemplo, um estágio.

• DML — estatísticas para consultas de linguagem de manipulação de dados (DML):

  • Number of rows inserted — número de linhas inseridas em uma tabela (ou tabelas).

  • Number of rows updated — número de linhas atualizadas em uma tabela.

  • Number of rows deleted — número de linhas excluídas de uma tabela.

  • Number of rows unloaded — número de linhas descarregadas durante a exportação de dados.

• Pruning — informações sobre os efeitos da remoção realizada na tabela:

  • Partitions scanned — número de partições verificadas até o momento.

  • Partitions total — número total de partições em uma determinada tabela.

• Spilling — informações sobre o uso do disco para operações onde os resultados intermediários não cabem na memória:

  • Bytes spilled to local storage — volume de dados despejados para o disco local.

  • Bytes spilled to remote storage — volume de dados despejados no disco remoto.

• Network — comunicação em rede:

  • Bytes sent over the network — quantidade de dados enviados pela rede.

• External Functions — informações sobre chamadas para funções externas:

  As seguintes estatísticas são mostradas para cada função externa chamada pela instrução SQL. Se a mesma função foi chamada mais de uma vez a partir da mesma instrução SQL, então as estatísticas são agregadas.

  • Total invocations — número de vezes que uma função externa foi chamada. (Isto pode ser diferente do número de chamadas de funções externas no texto da instrução SQL devido ao número de lotes em que as linhas estão divididas, o número de novas tentativas (se houver problemas transitórios na rede), etc.)

  • Rows sent — número de linhas enviadas para funções externas.

  • Rows received — número de linhas recebidas de volta das funções externas.

  • Bytes sent (x-region) — número de bytes enviados para funções externas. Se o rótulo incluir “(x-region)”, os dados foram enviados através de regiões (o que pode ter impacto no faturamento).

  • Bytes received (x-region) — número de bytes recebidos de funções externas. Se o rótulo incluir “(x-region)”, os dados foram enviados através de regiões (o que pode ter impacto no faturamento).

  • Retries due to transient errors — número de tentativas de repetição devido a erros transitórios.

  • Average latency per call — média de tempo por invocação (chamada) entre o momento em que Snowflake enviou os dados e o recebimento dos dados devolvidos.

  • HTTP 4xx erros — número total de solicitações de HTTP que retornaram um código de status 4xx.

  • HTTP 5xx erros — número total de solicitações de HTTP que retornaram um código de status 5xx.

  • Latency per successful call (avg) — latência média para solicitações de HTTP bem-sucedidas.

  • Avg throttle latency overhead — sobretaxa média por solicitação bem-sucedida devido a uma desaceleração causada pela limitação (HTTP 429).

  • Batches retried due to throttling — número de lotes que foram repetidos devido a erros HTTP 429.

  • Latency per successful call (P50) — latência de percentil 50 para solicitações de HTTP bem-sucedidas. 50 por cento de todas as solicitações bem-sucedidas levaram menos do que esse tempo para serem concluídas.

  • Latency per successful call (P90) — latência de percentil 90 para solicitações de HTTP bem-sucedidas. 90 por cento de todas as solicitações bem-sucedidas levaram menos do que esse tempo para serem concluídas.

  • Latency per successful call (P95) — latência de percentil 95 para solicitações de HTTP bem-sucedidas. 95 por cento de todas as solicitações bem-sucedidas levaram menos do que esse tempo para serem concluídas.

  • Latency per successful call (P99) — latência de percentil 99 para solicitações de HTTP bem-sucedidas. 99 por cento de todas as solicitações bem-sucedidas levaram menos do que esse tempo para serem concluídas.

• Extension Functions — informações sobre chamadas para funções de extensão:

  • Java UDF handler load time – quantidade de tempo para o manipulador da UDF de Java carregar.

  • Total de invocações do manipulador da UDF de Java — número de vezes que o manipulador da UDF de Java é invocado.

  • Max Java UDF handler execution time — quantidade de tempo máxima para que o manipulador da UDF de Java seja executado.

  • Avg Java UDF handler execution time — quantidade média de tempo para executar o manipulador da UDF de Java.

  • Java UDTF process() invocations — número de vezes que o método de processo da UDTF foi invocado.

  • Java UDTF process() execution time — quantidade de tempo para executar o processo da UDTF de Java.

  • Avg Java UDTF process() execution time — quantidade média de tempo para executar o processo da UDTF de Java.

  • Java UDTF’s constructor invocations — número de vezes que o construtor da UDTF foi invocado.

  • Java UDTF’s constructor execution time — quantidade de tempo para executar o construtor da UDTF de Java.

  • Avg Java UDTF’s constructor execution time — quantidade média de tempo para executar o construtor da UDTF de Java.

  • Java UDTF endPartition() invocations — número de vezes que o método endPartition da UDTF foi invocado.

  • Java UDTF endPartition() execution time — quantidade de tempo para executar o método endPartition da UDTF de Java.

  • Avg Java UDTF endPartition() execution time — quantidade média de tempo para executar o método endPartition da UDTF de Java.

  • Max Java UDF dependency download time — quantidade máxima de tempo para baixar as dependências da UDF de Java.

  • Max JVM memory usage — pico de uso de memória conforme relatado pelo JVM.

  • Java UDF inline code compile time in ms — tempo de compilação para o código inline da UDF de Java.

  • Python total UDF invocações do manipulador — número de vezes que o manipulador da UDF de Python foi invocado.

  • Total Python UDF handler execution time — tempo total de execução do manipulador da UDF de Python.

  • Avg Python UDF handler execution time — quantidade média de tempo para executar o manipulador da UDF de Python.

  • Python sandbox max memory usage — pico de uso de memória pelo ambiente sandbox do Python.

  • Avg Python env creation time: Download and install packages — quantidade média de tempo para criar o ambiente Python, incluindo download e instalação de pacotes.

  • Conda solver time — quantidade de tempo para executar o solucionador Conda para resolver pacotes Python.

  • Conda env creation time — quantidade de tempo para criar o ambiente Python.

  • Python UDF initialization time — quantidade de tempo para inicializar a UDF de Python.

  • Number of external file bytes read for UDFs — número de bytes de arquivos externos lidos para UDFs.

  • Number of external files accessed for UDFs — número de arquivos externos acessados para UDFs.

  Se o valor de um campo, por exemplo “Retries due to transient errors”, for zero, então o campo não é exibido.

Nós mais caros¶

O painel lista todos os nós que duraram 1% ou mais do tempo total de execução da consulta (ou o tempo de execução da etapa de consulta exibida, se a consulta foi executada em várias etapas de processamento). O painel lista os nós por tempo de execução em ordem decrescente, permitindo aos usuários localizar rapidamente os nós mais custosos em termos de tempo de execução.

Atributos¶

As seções seguintes fornecem uma lista dos tipos de operadores mais comuns e seus atributos:

“Explosão” de junções¶

Um dos erros comuns dos usuários de SQL é unir tabelas sem fornecer uma condição de junção (resultando em um “produto cartesiano”), ou fornecer uma condição em que os registros de uma tabela correspondem a vários registros de outra tabela. Para tais consultas, o operador Join produz significativamente (muitas vezes por ordem de magnitude) mais tuplas do que consome.

Isto pode ser observado verificando o número de registros produzidos por um operador Join, e normalmente também se reflete em um operador Join que consome muito tempo.

UNION sem ALL¶

Em SQL, é possível combinar dois conjuntos de dados com constructos UNION ou UNION ALL. A diferença entre eles é que UNION ALL simplesmente concatena as entradas, enquanto UNION faz o mesmo, mas também realiza a eliminação de duplicatas.

Um erro comum é usar UNION quando a semântica UNION ALL é suficiente. Estas consultas aparecem no perfil de consulta como um operador UnionAll com um operador extra Aggregate por cima (que realiza a eliminação de duplicatas).

Consultas grandes demais para caber na memória¶

Para algumas operações (por exemplo, eliminação de duplicatas para um conjunto de dados grande), a quantidade de memória disponível para os servidores usados para executar a operação pode não ser suficiente para armazenar resultados intermediários. Como resultado, o mecanismo de processamento de consultas começará a despejar os dados no disco local. Se o espaço em disco local não for suficiente, os dados despejados são salvos em discos remotos.

Este despejo pode ter um efeito profundo no desempenho da consulta (especialmente se for utilizado disco remoto para despejo). Para sanar isso, recomendamos:

• Usar um warehouse maior (aumentando efetivamente a memória disponível/espaço em disco local para a operação), e/ou

• Processar dados em lotes menores.

Remoção ineficiente¶

O Snowflake coleta estatísticas ricas em dados, permitindo não ler partes desnecessárias de uma tabela com base nos filtros de consulta. Entretanto, para que isso tenha efeito, a ordem do armazenamento de dados precisa ser correlacionada com os atributos do filtro de consulta.

A eficiência da remoção pode ser observada comparando as estatísticas de partições verificadas e partições totais nos operadores TableScan. Se a primeira for uma pequena fração da segunda, a remoção foi eficiente. Caso contrário, não teve efeito.

Naturalmente, a remoção só pode ajudar para consultas que realmente filtram uma quantidade significativa de dados. Se as estatísticas de remoção não mostram redução de dados, mas há um operador Filter acima de TableScan que filtra uma série de registros, isto pode sinalizar que uma organização de dados diferente pode ser benéfica para esta consulta.

Para obter mais informações sobre remoção, consulte Explicação das estruturas de tabela do Snowflake.