Uso de resultados de consultas persistentes¶
Quando uma consulta é executada, o resultado persiste (ou seja, é armazenado em cache) por um período. Ao fim do período, o resultado é purgado do sistema.
O Snowflake usa resultados de consulta persistentes para evitar repetir a geração de resultados quando nada mudou (ou seja, “otimização da recuperação”). Além disso, você pode usar os resultados de consulta persistentes para pós-processar os resultados (por exemplo, colocando uma nova consulta sobre os resultados já calculados).
Para resultados de consulta persistentes de todos os tamanhos, o cache expira após 24 horas.
Note que o token de segurança usado para acessar grandes resultados de consulta persistentes (ou seja, maiores que 100 KB em tamanho) expira após 6 horas. Um novo token pode ser recuperado para acessar os resultados enquanto eles ainda estão em cache. Resultados de consultas menores persistem e não utilizam um token de acesso.
Nota
O token fornecido ao Conector Snowflake para Spark (“conector Spark”) expira após 24 horas, independentemente do tamanho do resultado de consulta persistente. O conector Spark aproveita o maior tempo de expiração do cache para evitar o tempo limite em alguns casos de uso.
Consulte também Como otimizar o cache do warehouse, que discute como os dados da tabela podem ser armazenados em cache e reutilizados por um warehouse ativo.
Neste tópico:
Otimização da recuperação¶
Se um usuário repete uma consulta que já foi executada, e os dados na(s) tabela(s) não mudaram desde a última vez que a consulta foi executada, então o resultado da consulta é o mesmo. Em vez de executar a consulta novamente, Snowflake simplesmente retorna o mesmo resultado que retornou anteriormente. Isto pode reduzir substancialmente o tempo de consulta, pois o Snowflake ignora a execução da consulta e, em vez disso, recupera o resultado diretamente do cache.
Normalmente, os resultados das consultas são reutilizados se todas as seguintes condições forem atendidas:
- A nova consulta corresponde exatamente à consulta executada anteriormente. Qualquer diferença na sintaxe, incluindo letras minúsculas versus maiúsculas, ou o uso de aliases de tabela, inibirá 100% a reutilização do cache. Por exemplo, considere as seguintes consultas, executadas em sucessão: - SELECT DISTINCT(severity) FROM weather_events; SELECT DISTINCT(severity) FROM weather_events; SELECT DISTINCT(severity) FROM weather_events we; select distinct(severity) from weather_events; - A primeira consulta preencherá o cache, e a segunda consulta idêntica se beneficiará da reutilização de 100% do cache. No entanto, a terceira e a quarta consultas não acionarão a reutilização do cache, simplesmente porque a terceira consulta introduz um alias de tabela e a quarta consulta usa palavras-chave em letras minúsculas. 
- A consulta não inclui funções não reutilizáveis, que retornam resultados diferentes para execuções sucessivas da mesma consulta. UUID_STRING, RANDOM e RANDSTR são bons exemplos de funções não reutilizáveis. 
- A consulta não inclui funções externas. 
- A consulta não seleciona entre tabelas híbridas. 
- Os dados da tabela que contribuem para o resultado da consulta não foram alterados. 
- O resultado persistente para a consulta anterior ainda está disponível. 
- A função que acessa os resultados em cache tem os privilégios necessários. - Se a consulta foi uma consulta SELECT, a função que executa a consulta deve ter os privilégios de acesso necessários para todas as tabelas utilizadas na consulta em cache. 
- Se a consulta foi uma consulta SHOW, a função que executou a consulta deve corresponder à função que gerou os resultados em cache. 
 
- As opções de configuração que afetam a forma como o resultado foi produzido não mudaram. 
- As micropartições da tabela não foram alteradas (por exemplo, foram reagrupadas ou consolidadas) devido a mudanças em outros dados da tabela. 
Nota
O cumprimento de todas estas condições não garante que o Snowflake reutilize os resultados da consulta.
Por padrão, a reutilização dos resultados é ativada, mas pode ser substituída em nível de conta, usuário e sessão usando o parâmetro de sessão USE_CACHED_RESULT.
Nota
Cada vez que o resultado persistente de uma consulta é reutilizado, o Snowflake restabelece o período de retenção de 24 horas para o resultado, até um máximo de 31 dias a partir da data e hora em que a consulta foi executada pela primeira vez. Após 31 dias, o resultado é limpo e na próxima vez que a consulta é submetida, um novo resultado é gerado e persiste.
Pós-processamento dos resultados de consultas¶
Em alguns casos, você pode querer realizar um processamento adicional sobre o resultado de uma consulta que já tenha sido feita. Por exemplo:
- Você está desenvolvendo uma consulta complexa passo a passo e deseja adicionar uma nova camada sobre a consulta anterior e executar a nova consulta sem recalcular os resultados parciais a partir do zero. 
- A consulta anterior era uma instrução SHOW <objetos>, DESCRIBE <objeto> ou CALL, que retorna resultados em uma forma que não é fácil de reutilizar. - Por exemplo, você não pode chamar um procedimento armazenado dentro de uma instrução SQL mais complexa da maneira como você pode chamar uma função dentro de uma instrução SQL, então a única maneira de processar a saída do procedimento armazenado é pós-processar os resultados da consulta armazenada. 
Você pode executar o pós-processamento usando a função de tabela RESULT_SCAN. A função retorna os resultados da consulta anterior como uma «tabela» e, em seguida, você pode executar uma nova consulta nos dados tabulares.
Dica
Você também pode usar o operador de pipe (->>) em vez da função RESULT_SCAN para processar os resultados de um comando anterior. Com o operador de pipe, você não precisa exibir os resultados do comando inicial SELECT, SHOW ou outro comando.
Exemplos¶
Processe o resultado de um comando SHOW TABLES e extraia as seguintes colunas e linhas do resultado:
Colunas
schema_name,table_nameerows.
Linhas para tabelas que estão vazias.
SHOW TABLES; +-----+-------------------------------+-------------+-------+-------+------+ | Row | created_on | name | ... | ... | rows | +-----+-------------------------------+-------------+-------+-------+------+ | 1 | 2018-07-02 09:43:49.971 -0700 | employees | ... | ... | 2405 | +-----+-------------------------------+-------------+-------+-------+------+ | 2 | 2018-07-02 09:43:52.483 -0700 | dependents | ... | ... | 5280 | +-----+-------------------------------+-------------+-------+-------+------+ | 3 | 2018-07-03 11:43:52.483 -0700 | injuries | ... | ... | 0 | +-----+-------------------------------+-------------+-------+-------+------+ | 4 | 2018-07-03 11:43:52.483 -0700 | claims | ... | ... | 0 | +-----+-------------------------------+-------------+-------+-------+------+ | ... | | ... | +-----+-------------------------------+-------------+-------+-------+------+ -- Show the tables that are empty. SELECT "schema_name", "name" as "table_name", "rows" FROM table(RESULT_SCAN(LAST_QUERY_ID())) WHERE "rows" = 0; +-----+-------------+-------------+------+ | Row | schema_name | name | rows | +-----+-------------+-------------+------+ | 1 | PUBLIC | injuries | 0 | +-----+-------------+-------------+------+ | 2 | PUBLIC | claims | 0 | +-----+-------------+-------------+------+ | ... | | ... | +-----+-------------+-------------+------+
Exemplos adicionais são fornecidos em RESULT_SCAN.