Todos os produtos
Search
Central de documentação

PolarDB:Cache de tamanho de tabela (RSC)

Última atualização: Jun 28, 2026

O PolarDB for PostgreSQL (Compatible with Oracle) armazena em cache a contagem de blocos de tabelas e índices na memória compartilhada para reduzir chamadas ao sistema de arquivos durante a execução de SQL, diminuindo significativamente a latência das consultas.

Casos de uso

O cache de tamanho de tabela beneficia cargas de trabalho nas quais:

  • Alta proporção de leitura para escrita: Consultas verificam repetidamente as mesmas tabelas, tornando os acertos de cache frequentes e a redução de latência significativa.

  • Armazenamento distribuído: O cluster utiliza o PolarFS (Polar File System), onde cada chamada lseek para obter o tamanho do arquivo apresenta latência maior do que em sistemas de arquivos centralizados.

  • Aplicações sensíveis à latência: A latência de execução de SQL deve permanecer na faixa de sub-microssegundos para buscas de contagem de blocos.

Pré-requisitos

Antes de começar, verifique se você possui:

  • PolarDB for PostgreSQL (Compatible with Oracle) 2.0, versão de revisão 2.0.14.12.23.1 ou posterior

Visualize a versão de revisão no console ou execute SHOW polardb_version; . Atualize a versão de revisão se necessário.

Visualize a taxa de acerto

Use a extensão polar_monitor para visualizar os contadores reservados no caminho de código do RSC. Esses contadores permitem verificar a taxa de acerto para consultas e atualizações do RSC:

  • nblocks_pointer_hit: Número de acertos no índice de cache RSC de nível 1.

  • nblocks_mapping_hit: Número de acertos no índice de cache RSC de nível 2.

  • nblocks_mapping_miss: Número de falhas de cache RSC.

  • mapping_update_hit: Número de acertos para atualizações de cache RSC.

  • mapping_update_evict: Número de evicções durante atualizações de cache RSC.

  • mapping_update_invalidate: Número de invalidações durante atualizações de cache RSC.

CREATE EXTENSION IF NOT EXISTS polar_monitor;
SELECT * FROM polar_rsc_stat_counters();
-[ RECORD 1 ]-------------+------
nblocks_pointer_hit       | 45278
nblocks_mapping_hit       | 19561
nblocks_mapping_miss      | 196
mapping_update_hit        | 2523
mapping_update_evict      | 138
mapping_update_invalidate | 57

Uma taxa de acerto baixa pode indicar que o número de tabelas de ponto de acesso acessadas simultaneamente excede a capacidade do array de cache RSC, causando evicções frequentes. Se isso ocorrer, aumente o valor do parâmetro polar_rsc_shared_relations adequadamente para permitir que o array de cache RSC armazene a contagem de blocos de mais tabelas.

Como funciona

Arquitetura do RSC

O Relation Size Cache (RSC) é integrado ao gerenciador de armazenamento (smgr) e reside na memória compartilhada. Ele consiste em duas estruturas:

  • Array unidimensional: Cada entrada armazena a contagem de blocos de uma relação (tabela ou índice).

  • Tabela hash: Mapeia o identificador de cada relação (RelFileNode) para sua entrada no array. Um RelFileNode identifica exclusivamente uma relação na camada de armazenamento.

Fluxo de consulta

Todos os processos consultam o RSC usando dois níveis de índices antes de recorrer ao sistema de arquivos:

  1. Índice de nível 1: Cada processo armazena em cache ponteiros para entradas RSC acessadas recentemente, juntamente com seus números de geração. Durante uma busca, o processo verifica se o ponteiro corresponde à relação solicitada e se o número de geração permanece inalterado. Se ambas as condições forem verdadeiras, o processo lê a contagem de blocos diretamente do ponteiro. Esse nível oferece alta taxa de acerto para cargas de trabalho com muitas leituras. Quando a tabela hash do RSC é atualizada, os números de geração das entradas afetadas são incrementados automaticamente, invalidando quaisquer ponteiros de nível 1 obsoletos.

  2. Índice de nível 2: Em caso de falha de cache de nível 1, o processo consulta a tabela hash na memória compartilhada para localizar a entrada RSC. Após encontrá-la, ele lê a contagem de blocos e atualiza o índice de nível 1 para buscas futuras.

Se nenhum dos níveis encontrar a relação, a substituição de cache é acionada. O RSC usa o algoritmo Segmented Least Recently Used (SLRU) para evictar uma entrada raramente usada, chama lseek no sistema de arquivos para obter a contagem real de blocos, grava o resultado no slot evictado e atualiza ambos os índices.

Atualizações do RSC no nó primário

Qualquer função smgr que altere o tamanho de uma tabela também atualiza a entrada RSC correspondente na memória compartilhada de forma síncrona, mantendo a contagem de blocos em cache consistente com o tamanho real do arquivo:

  • Extensão de uma tabela: A nova contagem de blocos é gravada no RSC imediatamente.

  • Truncamento de uma tabela: A contagem de blocos atualizada é gravada no RSC imediatamente.

Atualizações do RSC em nós standby

Os nós standby usam replicação física para permanecer sincronizados com o nó primário. Durante a reprodução do WAL (Write Ahead Log), os nós standby invocam as mesmas funções smgr usadas no nó primário; portanto, as atualizações do RSC nos nós standby são tratadas de forma idêntica às do nó primário.

Atualizações do RSC em nós réplica

Os nós réplica compartilham armazenamento físico com o nó primário e sincronizam por meio de índices de log. Como são somente leitura, não podem chamar funções smgr para atualizar o RSC diretamente.

Em vez disso, os nós réplica analisam registros WAL para detectar alterações de armazenamento:

  • Aumento da contagem de blocos: Se um registro WAL referenciar um número de sequência de bloco superior à contagem em cache, a entrada RSC será atualizada para a contagem real de blocos.

  • Invalidação de cache: Se um registro WAL indicar truncamento de tabela, a contagem de blocos em cache será invalidada. A próxima chamada ao sistema de arquivos para essa tabela repovoará o RSC com a contagem real.

Parâmetros GUC

Os seguintes parâmetros Grand Unified Configuration (GUC) controlam o RSC. Valores válidos para todos os parâmetros: on | off.

Parâmetro

Descrição

Padrão

polar_enable_rel_size_cache

Ativa o recurso RSC.

on

polar_enable_replica_rel_size_cache

Ativa o RSC para nós réplica.

on

polar_enable_standby_rel_size_cache

Ativa o RSC para nós standby.

on

polar_rsc_pool_sweep_times

Define o número máximo de entradas de cache RSC a serem verificadas em sequência durante a evicção de cache. Se nenhuma entrada evictável for encontrada após verificar esse número de entradas, uma entrada aleatória será evictada. Não é necessário alterar o valor padrão.

polar_rsc_shared_relations

Define o número de entradas de cache RSC. Não é necessário alterar o valor padrão.

Benchmarks de desempenho

Os resultados a seguir mostram a latência de consulta de contagem de blocos para uma tabela de 32 GB com o RSC desativado e ativado.

RSC desativado — latência ~55 microssegundos:

SHOW polar_enable_rel_size_cache;
 polar_enable_rel_size_cache
-----------------------------
 off
(1 row)

SELECT polar_smgrperf_nblocks(32, true, false);
NOTICE:  testing logical file length with 32 GB
INFO:  iops=18341.1/s, lat=54.52us
INFO:  iops=17504.0/s, lat=57.13us
INFO:  iops=17960.8/s, lat=55.68us
INFO:  iops=17973.0/s, lat=55.64us
INFO:  iops=17603.5/s, lat=56.81us
INFO:  iops=17403.8/s, lat=57.46us
INFO:  iops=17506.2/s, lat=57.12us
INFO:  iops=18061.7/s, lat=55.37us

RSC ativado — latência ~0,07 microssegundos:

SHOW polar_enable_rel_size_cache;
 polar_enable_rel_size_cache
-----------------------------
 on
(1 row)

SELECT polar_smgrperf_nblocks(32, true, false);
NOTICE:  testing logical file length with 32 GB
INFO:  iops=14155515.6/s, lat=0.07us
INFO:  iops=13897273.6/s, lat=0.07us
INFO:  iops=13869926.3/s, lat=0.07us
INFO:  iops=13779602.7/s, lat=0.07us
INFO:  iops=14159120.5/s, lat=0.07us
INFO:  iops=14147065.6/s, lat=0.07us
INFO:  iops=14124141.9/s, lat=0.07us
INFO:  iops=14162773.3/s, lat=0.07us

Com o RSC ativado, as buscas de contagem de blocos tornam-se aproximadamente 800 vezes mais rápidas, eliminando a chamada ao sistema de arquivos do caminho crítico de execução de SQL.