Noções Básicas de Carga de Trabalho

OLTP deseja transações curtas de baixa latência. OLAP deseja varreduras grandes, ordenações e paralelismo. A mesma instância PostgreSQL 18.4 não pode maximizar ambos sem barreiras de proteção ou divisões de topologia.

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

-- Padrões de função OLTP
ALTER ROLE oltp_app SET statement_timeout = '5s';
ALTER ROLE oltp_app SET work_mem = '16MB';
 
-- Padrões de função de relatórios (pool separado)
ALTER ROLE reporting SET statement_timeout = '30min';
ALTER ROLE reporting SET work_mem = '256MB';

Quando usar isso: Projetando padrões de cluster antes de misturar a API de checkout e os dashboards de BI em um primário.

Exemplo de Trabalho

CREATE TABLE orders (
  id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  customer_id bigint NOT NULL,
  total numeric(12,2) NOT NULL,
  created_at timestamptz NOT NULL DEFAULT now()
);
 
INSERT INTO orders (customer_id, total, created_at)
SELECT (random() * 10000)::bigint, (random() * 500)::numeric(12,2), now() - (random() * interval '365 days')
FROM generate_series(1, 500000);
 
-- Forma OLTP: leitura pontual
EXPLAIN (ANALYZE, BUFFERS)
SELECT total FROM orders WHERE id = 12345;
 
-- Forma OLAP: varredura de agregação
EXPLAIN (ANALYZE, BUFFERS)
SELECT date_trunc('month', created_at) AS month, sum(total)
FROM orders
GROUP BY 1
ORDER BY 1;

O que isso demonstra:

• Formas de plano contrastantes (busca de índice vs. varredura sequencial + ordenação/agregação de hash)
• Por que um padrão work_mem atende mal a ambos
• Necessidade de roteamento ou separação de funções

Análise Profunda

Como Funciona

• OLTP: muitas consultas curtas concorrentes, amigáveis a índices, sensíveis a bloqueios e contagem de conexões.
• OLAP: menos consultas pesadas, E/S sequencial, trabalhadores paralelos, memória grande por operador.
• Configurações conflitantes: work_mem, max_parallel_workers_per_gather, effective_io_concurrency, statement_timeout.
• Cache de buffer compartilhado: varreduras grandes removem páginas OLTP quentes (poluição de cache).

Tabela de Conflito de Configurações

Notas SQL

SELECT rolname, rolconfig
FROM pg_roles
WHERE rolname IN ('oltp_app', 'reporting');

Armadilhas

• Ferramentas de BI na conexão padrão do primário - Varredura noturna bloqueia o checkout. Correção: Pool de réplicas mais função de relatórios.
• work_mem global alto para "relatórios lentos" - Ordenações OLTP herdam risco de OOM. Correção: work_mem por função apenas em relatórios.
• Consulta paralela em consultas OLTP minúsculas - Sobrecarga paralela prejudica. Correção: max_parallel_workers_per_gather = 0 para função OLTP opcional.
• Mesmos índices para OLTP e OLAP - Índices de cobertura amplos prejudicam gravações. Correção: MVs específicas da réplica ou exportação colunar.
• Ignorando efeitos de cache - Uma varredura de tabela completa degrada toda a instância. Correção: Isolar topologia de análise.

Alternativas

FAQs

Relacionado

• Réplicas de Leitura para Relatórios - Topologia
• Consulta Paralela - Quando habilitar
• Ajuste de work_mem - Divisão de memória
• Função e Tempo Limite por Pool - Aplicação

Versões da pilha: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.