Ativar custos com reconhecimento de cache para planos de consulta de verificação de índice

Esta página documenta o reconhecimento de cache durante as verificações de índice. Quando ativado, o planejador de consultas do AlloyDB para PostgreSQL ajusta o custo estimado de E/S das verificações de índice com base em quantas páginas de índice e tabela já estão disponíveis no buffer compartilhado quando a execução começa. O plano de consulta final é selecionado com base nos custos ajustados. Isso melhora o desempenho da consulta e reduz os custos do banco de dados.

Depois de ativada, a função de reconhecimento de cache funciona automaticamente e se ajusta ao status de acerto do buffer compartilhado. Além disso, a capacidade de reconhecimento do cache pode funcionar com outras práticas de ajuste de consultas, como definir a estimativa de custo do planejador de consultas do AlloyDB como random_page_cost.

Dica: recomendamos que você ative o reconhecimento de cache se notar que o planejador de consultas não seleciona planos de consulta melhores com base na verificação de índice.

Ativar a compatibilidade com cache

Para ativar a capacidade de reconhecimento de cache na sua instância do AlloyDB, defina a flag alloydb.enable_cache_aware_costing (prévia) como on. Além disso, é possível definir a flag no nível da sessão para afetar os planos de consulta que ocorrem na mesma sessão. Para saber como definir a flag, consulte Configurar flags de banco de dados de uma instância.

Exemplo de cenário

O exemplo de código a seguir mostra um plano de verificação de índice executado com um cache de buffer compartilhado totalmente aquecido.

explain (analyze, verbose, buffers)
SELECT count(d) FROM t1 WHERE a = 10 AND b > 100 AND c > 100;

------------------ Aggregate  (cost=3908.93..3908.94 rows=1 width=8) (actual time=4.128..4.130 rows=1 loops=1)
   Output: count(d)
   Buffers: shared hit=926
   ->  Index Scan using idx1 on public.t1  (cost=0.43..3906.49 rows=975 width=2) (actual time=0.143..3.205 rows=919 loops=1)
         Output: a, b, c, d
         Index Cond: ((t1.a = 10) AND (t1.b > 100) AND (t1.c > 100))
         Buffers: shared hit=926
   Execution Time: 4.353 ms

Durante essa execução, não houve leituras de E/S. Sem reconhecimento de cache, o planejador de consultas inclui o custo de E/S para o plano de consulta de verificação de índice. Isso pode fazer com que o plano de consulta de verificação de índice perca para um plano de consulta de verificação sequencial.

O snippet de código a seguir mostra o custo ajustado do plano de consulta quando o reconhecimento de cache está ativado.

explain (verbose)
SELECT count(d) FROM t1 WHERE a = 10 AND b > 100 AND c > 100;

------------------ Aggregate  (cost=29.93..29.94 rows=1 width=8)
   Output: count(d)
   ->  Index Scan using idx1 on public.t1  (cost=0.43..27.49 rows=975 width=2)
         Output: a, b, c, d
         Index Cond: ((t1.a = 10) AND (t1.b > 100) AND (t1.c > 100))

O novo custo, 27.49, para o mesmo plano de consulta de verificação de índice é muito menor do que o custo antigo, 3906.49.