Conceptos básicos de la carga de trabajo

OLTP busca transacciones cortas de baja latencia. OLAP busca escaneos grandes, ordenaciones y paralelismo. La misma instancia de PostgreSQL 18.4 no puede maximizar ambos sin barreras de protección o divisiones de topología.

Receta

Tarjeta de referencia rápida, lista para copiar y pegar.

-- Valores predeterminados del rol OLTP
ALTER ROLE oltp_app SET statement_timeout = '5s';
ALTER ROLE oltp_app SET work_mem = '16MB';
 
-- Valores predeterminados del rol de informes (pool separado)
ALTER ROLE reporting SET statement_timeout = '30min';
ALTER ROLE reporting SET work_mem = '256MB';

Cuándo usar esto: Diseño de valores predeterminados del clúster antes de mezclar la API de pago y los paneles de BI en un primario.

Ejemplo de trabajo

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: lectura puntual
EXPLAIN (ANALYZE, BUFFERS)
SELECT total FROM orders WHERE id = 12345;
 
-- Forma OLAP: escaneo de agregación
EXPLAIN (ANALYZE, BUFFERS)
SELECT date_trunc('month', created_at) AS month, sum(total)
FROM orders
GROUP BY 1
ORDER BY 1;

Lo que esto demuestra:

• Formas de plan contrastantes (búsqueda de índice vs escaneo secuencial + ordenación/hash agg)
• Por qué un valor predeterminado de work_mem sirve mal a ambos
• Necesidad de enrutamiento o separación de roles

Análisis en profundidad

Cómo funciona

• OLTP: muchas consultas cortas concurrentes, amigables con índices, sensibles a la espera de bloqueos y al número de conexiones.
• OLAP: menos consultas pesadas, E/S secuencial, trabajadores paralelos, memoria grande por operador.
• Perillas en conflicto: work_mem, max_parallel_workers_per_gather, effective_io_concurrency, statement_timeout.
• Caché de búferes compartida: los escaneos grandes expulsan páginas OLTP activas (contaminación de caché).

Tabla de conflicto de perillas

Notas de SQL

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

Trampas comunes

• Herramientas de BI conectadas al pool primario por defecto - El escaneo nocturno bloquea el proceso de pago. Solución: Pool de réplicas más rol de informes.
• work_mem global alto para "informes lentos" - Las ordenaciones OLTP heredan el riesgo de OOM. Solución: work_mem por rol solo en informes.
• Consulta paralela en consultas OLTP diminutas - La sobrecarga paralela perjudica. Solución: max_parallel_workers_per_gather = 0 para el rol OLTP opcional.
• Mismos índices para OLTP y OLAP - Los índices de cobertura amplios perjudican las escrituras. Solución: MVs específicas de réplica o exportación columnar.
• Ignorar los efectos de la caché - Un escaneo completo de la tabla degrada toda la instancia. Solución: Aislar la topología de análisis.

Alternativas

Preguntas frecuentes

Relacionado

• Réplicas de lectura para informes - Topología
• Consulta paralela - Cuándo habilitar
• Ajuste de work_mem - División de memoria
• Rol y tiempo de espera por pool - Aplicación

Versiones de la pila: Esta página se escribió para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x y PostGIS 3.5+.